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@lists.freeradius.org [mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk@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
Franks Andy (RLZ) IT Systems Engineer wrote:
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..
Single-threaded versus multiple threads doesn't usually make a big difference.
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,
Any modern CPU should be able to do 100's of EAP sessions per second. If yours can't do that, it was under-provisioned. That's why adding more CPUs helped: you gave it more CPU power.
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.
Well, that's a switch problem.
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?
That's one huge sentence. I can't make heads or tails of it. Alan DeKok.
participants (2)
-
Alan DeKok -
Franks Andy (RLZ) IT Systems Engineer