mschap via ntlm_auth over a socket
mcn4 at leicester.ac.uk
Fri Dec 5 01:46:03 CET 2014
On Thu, Dec 04, 2014 at 02:38:06PM +0000, Phil Mayers wrote:
> On 03/12/14 14:00, Matthew Newton wrote:
> >Debian wheezy - winbind 3.6.6.
> >lsof shows 5 connections to a single DC, as you say. But tcpdump
> >shows essentially all connections coming from a single TCP source
> >Also, winbind debug logs (-d4) show each request with "child
> >daemon request 14" / "Finished processing child request 14", which
> Both those imply to me that winbind isn't seeing the need to use a
> parallel connection, almost as if the *offered* load is being
> limited before hitting winbind pipe dispatch, as opposed to anything
I did semi wonder about that, then got into the thought that the
ntlm_auth exec/setup may be the slow bit, hence looking at the
helper option. I've not dug much more into the winbind side
> Concurrency in winbind prior to the dispatch? Or before connecting
> to the pipe e.g. locking inside the .tdb files?
Hmm, is it really hitting disk for each auth? That wouldn't help.
I might try sticking /var/lib/samba on tmpfs temporarily and see
if it makes any difference.
> We're on pretty quick hardware that might be hiding some of these now.
These are on fairly small Xen VMs. 2 CPU; was on 384mb RAM, but
bumped it up to a gig as there was a little in swap, but they
weren't actively swapping. Now there's stacks of free RAM, so I
don't think there was any issue there really.
The biggest thing we've done which has helped clear the mud from
the water was to stop the wireless controllers jumping RADIUS
server at the first sign of trouble. They were moving around every
30s or so at peak periods which makes the problem far far worse as
all EAP sessions get chopped off and everything has to start
again, compounding the issue.
> >Thanks. Actually, on a quiet RADIUS server it looks like the
> >normal request time is just over 1ms. I guess the question is if
> >it goes up significantly for a busy server, which that would show.
> For an MSCHAP auth RPC, round-trip, or ntlm_auth start-to-end?
Sorry, tcpdump roundtrip - time from first packet to DC, to
response from DC.
> However, there's a very odd double-peak structure to the ntlm_auth
> times with a second, much smaller peak at around 50-60msec, which I
> don't know the cause of.
Login failures, maybe?
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>
More information about the Freeradius-Devel