Maybe that impression stems from reading on multiple sites (other than yours) that the radiusd.conf shouldn't be modified and that the how-to says to add the exec ntlm_auth and some other variables to the radiusd.conf, instead of to the /modules subdir. Maybe I should just ignore the other information I've read about not modifying the radiusd.conf file (which I will now do). After commenting out the changes to mschap (the ntlm_auth command used in that file) and adding the exec ntlm_auth to the radiusd.conf and to the /sites-enabled/default radiusd still seems to be ignoring the ntlm_auth request from my switch; I have double and triple checked that winbindd and krb5 are both operating quite well. [from radiusd -X] Module: Checking authenticate {...} for more modules to load Module: Instantiating ntlm_auth exec ntlm_auth { wait = yes program = "/usr/bin/ntlm_auth ntlm_auth --request-nt-key --domain=MYDOMAIN --username=%{mschap:User-Name} --password=%{User-Password}" input_pairs = "request" shell_escape = yes } [output of authentication attempt] Ready to process requests. rad_recv: Access-Request packet from host *.*.*.200 port 1645, id=13, length=102 User-Name = "windoze_luser" User-Password = "<sekrat>" NAS-Port = 1 NAS-Port-Id = "tty1" NAS-Port-Type = Virtual Calling-Station-Id = "*.*.*.92" NAS-IP-Address = *.*.*.200 +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "windoze_luser", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound [files] users: Matched entry DEFAULT at line 212 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = Local WARNING: Please update your configuration, and remove 'Auth-Type = Local' WARNING: Use the PAP or CHAP modules instead. No "known good" password was configured for the user. As a result, we cannot authenticate the user. Failed to authenticate the user. Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> windoze_luzer attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 0 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 0 Sending Access-Reject of id 13 to 192.168.0.200 port 1645 Waking up in 4.9 seconds. Cleaning up request 0 ID 13 with timestamp +19 Ready to process requests.
? It's up to date with the most recent version of the server. Can you describe what's wrong about the document?
Alan DeKok.