ntlm_auth improvements

[Matthew Newton]

Hi,

Just opening up for a bit of discussion on the best way to proceed
with the ntlm_auth improvements I've been hacking around on.

I've just been testing using libwbclient from FreeRADIUS. One
RADIUS server has held up our entire wireless infrastructure for a
couple of days, over all student movements between lectures,
without a single complaint from the Cisco controllers about RADIUS
timeouts.

We normally hit problems when one RADIUS server gets to about 30
auths/second. This one has peaked at nearly 90 auths/second. This
is nice - it seems execing ntlm_auth really is the problem (this
is Samba 3.6.6, all running on HP DL380G6, 2-CPU Xen VMs ~1Gb RAM
[mostly unused]).

However -

  1. It's running a version of libwbclient that has pthread
  support that can't be merged into Samba for a couple of reasons.
  It's safe for FR to use, but not for e.g. pam_winbind. So I'm
  working on a bigger Samba patch that hopefully can be merged.

  2. Even when I get it done and it is merged into Samba, I guess
  it'll be a good couple of years or so before the code gets into
  distributions.

  3. We could put a mutex around wbcAuthenticateUserEx (have
  tried, this works safely without a Samba patch) but that defeats
  the point of being able to do more than one authentication
  simultaneously.

I've been unable to test FR3 yet. That would let me try the
ntlm_auth helper option instead, which I can't easily try in FR2.
I believe that this will offer similar performance improvements.
It's on the list, but will take a while.

When you look at the way ntlm_auth works, it connects to the
winbind unpriv socket, 1 call over it to get the interface
version, another call to get the priv socket location, closes the
first socket, opens the priv socket, then sends the auth query.
Using the ntlm_auth helper mode, and calling libwbclient directly,
both do the first lot of setup once only, which means each auth
goes straight to just doing the auth query. It's not surprising
that doing a fork/exec, then all that setup first slows things
down.


So wondering what the best thing to do for FR is - noting pull
request 848, which can't be merged as-is as it's unsafe with
libwbclient.

My thoughts are -

Add ntlm_auth helper mode to 3.0.x now, which should be safe and
run on anything that has ntlm_auth. And will be, IMO, nearly as
fast as calling libwbclient directly. This should fix the AD auth
issues for anyone with FR3. (I'm happy to provide patches as-is
for Samba and FR2 for any that want, but they're not going to be
merged.)

Finish and submit patch to Samba, then add libwbclient mode either
later on in 3.0.x or more likely to 3.1.x, due to the timescales
of the Samba release.

In discussions with the Samba guys, the API will change to do this
anyway, which makes a configure test easy to determine if
libwbclient is thread-safe. If not, then this method must be
disabled.

Thoughts?

Cheers

Matthew
(who still can't believe it's possible that one small
RADIUS server is handling our entire auth+acct load)


-- 
Matthew Newton, Ph.D. <mcn4 at le.ac.uk>

Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>