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@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>