time delay in ntlm_auth?
Hi, I have just been timing my 2.1.12 setup in Debian 7, authenticating in an AD via samba 3.6.6, and selecting VPN via LDAP groups. The point is that a EAP connections can take around 162ms-190ms, of which 30ms account to the EAP negotiation, 13-20ms taken in ntlm_auth running in command line, and around 100 ms more when processing mschap/ntlm_auth inside freeradius. Any ideia where I could find the culprit, or profile it? I suspect it is due to the forking of ntlm_auth. The CPU is practically idle with a couple thousand users per day. No lack of memory too. Finally, do you find 160ms-200ms an acceptable time to authenticate, or do I need to dig it further on? Regards, Rui Ribeiro
Rui Ribeiro wrote:
Finally, do you find 160ms-200ms an acceptable time to authenticate, or do I need to dig it further on?
It should be fine. The "unresponsive child" message will occur only after "max_request_time". i.e. 30 seconds. If a request takes more than 30s to process, then something is *very* wrong. It may indicate that the ntlm_auth program has hung. I'll take a look at writing a "wrapper" program to deal with this issue. It should take an argument of time to wait, and then the other program to execute. Then if the second program takes too long, kill it, and return an error. e.g. wait_limit -t 5 /path/to/ntlm_auth ... args ... Where "wait_limit" is a small C program. It would wait 5 seconds, and if ntlm_auth didn't return, kill it, and return a failure to radiusd. That would work around the "unresponsive child" issue, but not solve it. The underlying issue is that *something* is blocking ntlm_auth for 30s at a time. That's bad. Alan DeKok.
Hi, On Tue, Oct 15, 2013 at 05:09:39PM -0400, Alan DeKok wrote:
Where "wait_limit" is a small C program. It would wait 5 seconds, and if ntlm_auth didn't return, kill it, and return a failure to radiusd.
I've just sent a pull request that adds an option 'timeout' to rlm_exec and 'ntlm_auth_timeout' to rlm_mschap. Defaults are both 10s (the current setting). The ntlm_auth timeout can only be reduced... I can't imagine a correctly functioning AD domain where a successful auth takes >10s. Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@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@le.ac.uk>
Hi,
I've just sent a pull request that adds an option 'timeout' to rlm_exec and 'ntlm_auth_timeout' to rlm_mschap. Defaults are both 10s (the current setting). The ntlm_auth timeout can only be reduced... I can't imagine a correctly functioning AD domain where a successful auth takes >10s.
how does this sort of thing interplay with those people who are using the MSCHAP password retry feature - which would, I believe, cause the module itself not to return until the user has finally put in a succesful password - which might be longer than eg 30s alan
Hi, On Wed, Oct 16, 2013 at 10:00:45AM +0100, A.L.M.Buxey@lboro.ac.uk wrote:
I've just sent a pull request that adds an option 'timeout' to rlm_exec and 'ntlm_auth_timeout' to rlm_mschap. Defaults are both 10s (the current setting). The ntlm_auth timeout can only be reduced... I can't imagine a correctly functioning AD domain where a successful auth takes >10s.
how does this sort of thing interplay with those people who are using the MSCHAP password retry feature - which would, I believe, cause the module itself not to return until the user has finally put in a succesful password - which might be longer than eg 30s
I don't think this will be an issue - that will be eap/radius timers? The current hardcoded timeout for an exec is 10 seconds, so ntlm_auth could never be running for longer than that or it will get killed off. I've not looked at it, but I assume any password retries will re-run ntlm_auth each time (it can't pass a new password to an existing one, as it's passed on the command line - which I guess the pipe thing is all about fixing). Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@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@le.ac.uk>
Matthew Newton wrote:
I've just sent a pull request that adds an option 'timeout' to rlm_exec and 'ntlm_auth_timeout' to rlm_mschap. Defaults are both 10s (the current setting). The ntlm_auth timeout can only be reduced... I can't imagine a correctly functioning AD domain where a successful auth takes >10s.
It's pretty much exactly what I would have done. I'll pull it into 3.0, too. Alan DeKok.
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Matthew Newton -
Rui Ribeiro