Help with chap

[Franks Andy (RLZ) IT Systems Engineer]

Thanks for the help.
  Anecdotally, before I get into serious discovery, I've been running
the freeradius process in extra debugging mode -xx. I'd read somewhere
that -X makes it run single threaded, but along those lines of thinking
I wondered if -xx and the extra debug was causing any performance
issues. I may be off at completely the wrong tangent, but the problem is
interesting and I like the odd tangent..
Anyway, anecdotally as I said, with the server running in fresh from a
reboot, no debugging, and upping the vm to 4 core instead of 1 (just
playing), the problem seems vastly reduced. Nearly all clients are
authenticated within 10 seconds, the consistent off ones are some
ancient mitel voip phones with pcs running off the back, which the
switch simply doesn't "see" for ages. It just sits there and eventually
just sends an auth request. In many cases the switch "sec" debug doesn't
even report the mac address or any activity for this weird phone, but
the FR linelog shows it authenticated fine. Really strange.
Any else got any reports of the procurve switches just sitting there
waiting for something to happen?
The failure of the responses seemed previously to have kicked the switch
into waiting ages then retrying later (the retry is set to 30 seconds
but it was way longer). Anyway, the lack of debug seems to have helped
quite a bit.

By the way, if I was to do chap, since I'm running ldap against AD - no
available plaintext or other passwords, but I'm running mac-based auth,
can I just use the authorize process to check for "notfound" and check
the useraccountcontrol setting is correct from an attribute mapping (or
just use the useraccountcontrol in an ldap filter and rely on not
found), then just set the cleartext-password attribute to be
%{username} using some more unlang , then do nothing special in the chap
authentication bit, just let it "ok" with the plaintext password or is
that just all wrong? I figure I don't *really* need a password for
mac-based auth, since it's always going to be == to the username?

Thanks for the input
Andy

-----Original Message-----
From:
freeradius-users-bounces+andy.franks=sath.nhs.uk at lists.freeradius.org
[mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk at lists.freeradiu
s.org] On Behalf Of Alan DeKok
Sent: 20 May 2013 14:01
To: FreeRadius users mailing list
Subject: Re: Help with chap

Franks Andy (RLZ) IT Systems Engineer wrote:
> Thanks Alan,
>   It takes literary a second or so for a single client auth, but
> problems arise with multiple clients. I'll reset a card on the switch
> and capture the logs and see what's happening. Nothing as far as I
> remember pointed towards the ntlm_auth being the issue, it was the
> failure to complete the eap transaction that seemed to be the problem,
> but then I didn't scan each and every line to be honest.

  See http://deployingradius.com/

  It has instructions for testing PEAP via eapol_test.  That lets you do
some limited performance checks.

  An alternative is to configure a static user/password.  Do performance
checks using that user.  If it's a lot faster than ntlm_auth, then the
problem is likely ntlm_auth.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html