[Samba] Re: [PATCH] Add winbind-backed NTLMSSP support to Cyrus-SASL

[Andrew Bartlett]

On Wed, Dec 31, 2003 at 12:49:45PM -0500, Ken Murchison wrote:
> Andrew Bartlett wrote:
> 
> > Windows authentication extends far beyond the CIFS protocol the Samba
> > implements, but it only very recently that work has been done to catch
> > up to Microsoft's extensions in this area.  This has caused many
> > administrators pain and toil that their MS counterparts simply don't
> > have.  For them, authentication 'just works', with single-sign-on and
> > the lot.
> > 
> > I have worked, for over a year, with the Squid development team, in
> > extending NTLMSSP authentication to HTTP.  The squid team made a very
> > good start (as I see Cyrus-SASL now has) in including a basic NTLMSSP
> > implementation, and even providing a proxy-mechanism to authenticate
> > against a Windows DC.  I extended on this base, providing the
> > ntlm_auth tool, which allows them to perform this against winbind, and
> > without having to understand NTLMSSP as anything more than BASE64 strings.
> > 
> > This provides a much more reliable interface, as winbind is not only faster, 
> > we can also prevent man-in-the-middle attacks.
> > 
> > The attached patch provides this for Cyrus-SASL.  In the same was that
> > Squid now uses Winbind, all Cyrus-SASL enabled applications can use
> > Winbind (via ntlm_auth) to authenticate their users.  This provides
> > the most current NTLMSSP implementation in the Open Source arena, as
> > it is the one that we must maintain for Samba's internal use.
> > 
> > The plugin is designed to use ntlm_auth over a stdio interface,
> > because as part of Samba, it is GPL'ed.  The plugin provides a client,
> > and an server implementation, but can only proxy it's server-side (I
> > can provide a mode that allows for local passwords if it is required).
> > 
> > Current Samba 3.0 CVS is required to find the NTLMSSP client code exposed.
> 
> Here is my opinion, Rob's *may* differ:
> 
> Having support for all of the latest NTLMSSP stuff is a great idea, but 
> I don't think we want to have yet another dependency for Cyrus SASL, 
> especially unreleased Samba code.

This will be in Samba 3.0.2, which I expect to be released in a
reasonalbly short timeframe due to issues in 3.0.1 (but the rest is up
to the release manager)

(BTW, when on an MS system I suggest the use of MS's SSPI interface,
as that will give you 'perfect' NTLMSSP on that platform)

I was very pleased to see what appears to be a reasonably mature
NTLMSSP implemenation.  However, a few things stood out - common
errors in most of the NTLMSSP implentations I have seen:

Firstly, Unicode != ASCII plus NULL bytes.  i18n is no longer an
'interesting idea', it is something that people not only want to have
function, but particularly those from the MS world *expect* to just
function.  

Secondly, domains and workstations do matter.  The domains you will
see as soon as you move to any 'enterprise' site, with multiple
trusted domains.  The the 'workstation' regards the list of
workstations that a user may log into, as restricted by the DC.  (It
may be a lame 'security' measure, but we have to get the values right,
as some sites do enforce it).

Naturally, things like NTLM2, KEY_EXCH are not supported, but this
doesn't supprise me, as they have not yet become mandetory.  (I'm told
Longhorn may change this)

> I also think that being able to use passwords that are stored in an 
> auxprop plugin is mandatory as there might be sites which want to 
> support MS clients but don't have an MS server to proxy to.

They can always use a Samba server :-)

But seriously, if it is required, we can add a callback.  

> Can you point me to any references to Winbind, so I at least know what 
> we are missing?

My bigest concern is the 'proxy' implementation being developed.

In my time working on authentication for the Samba Team, I have seen
many attempts at intergrating windows passwords into the unix world.
I have seen Samba's own 'security=server', pam_smb, mod_auth_smb, the
original Apache NTLM module, the original squid helpers.  All of these
suffered a fundemantal failing: 

They are inherintly insecure to a man-in-the-middle attack between the
server performing the authentication proxy and the DC with the
passwords.

They are also highly unreliable, in our experience.  This is
particularly so when 'optomisations' have been added to get around the
connection setup time.

Winbind provides a service for managing the connection to the DC.
However, more important is the difference (in samba terms) between
'security=domain' and 'security=server'.  

What winbind provides to ntlm_auth is the ability to specify the
challange and response in the same packet, and to send this packet
over a secured link.  By using only one packet, we cannot 'loose' the
connection between stages of the authenticaiton protocols, and if the
connection is lost, we may simply retry.  We can even choose to talk
to a new Domain Controller (a Backup perhaps).  Winbind uses the same
Domain Controller docation methods as the rst of Samba.  This avoids
hard-coded server names, and increases the degree to which this 'just
works'.  These combine to drasticly reduces spurious authentication
failures.

It is also *very* fast.  With only one packet in each direction (plus
TCP ACKs) a high, the latency experienced by clients is drasticly
reduced.  Due to the nature of HTTP, Squid uses this particualrly.
(indeed, this was the reason for much of this work in the first
place).

This is achived because Samba uses the NT domain membership protocols,
and partipates as a full member of the domain.

Technically, ntlm_auth is a winbind client, and simply askes winbind
to handle this part of the operation.  In the past, the Squid helpers
were also winbind clients.  This worked, until Samba changed its
interface...  This is why I provide the full NTLMSSP interface, on a
program that I can ensure does not very in its behaviour, even if
Samba's internals change.  This way, I kill too birds with one stone.

> > Patch against current SASL CVS, but my testing was actually with 2.1.15
> 
> I wanted to take a look at your code, but this patch does not apply 
> cleanly to CVS -- only 1 of 7 hunks succeeds.

I'll try again on the patch.

http://hawkerc.net/staff/abartlet/ntlm_sasl.diff

Andrew Bartlett