Follow-up to myself,
As you see, no proxying (no suffix module at all) nor EAP-Message in the debug log.
Ah, there is a suffix instance but it does nothing, noop.
I have looked at other occasions where NT-Password gets used (e.g. we have a vserver which pulls it out of SQL). I guess I should be seeing that normify() outputs something in the debug output I sent - but not at all. It is hex-encoded though, so the RDEBUG2 inside normify can't possibly be silent.
This makes me believe that the NT-Password is not actually evaluated . But then again, the log also says that the line matched, so it should really get going.
Wondering about inst->normify - that's inside an if. Maybe it is false, so pw_found is set to true, but the normifying is never done? I also see that instantiate() does not set inst->normify. Does it have to? Not good enough in C to answer this.
Found that it is set in config. My pap module config is really minimal: pap { auto_header = no } It doesn't set normalise, and as per code it then defaults to "yes". So inst->normify should do its job. Which means I'm more clueless than before, if that's even possible :-( Stefan
I should also note that other clients are mapped to the same virtual server - and check the password correctly. It only fails deterministically for two clients of that virtual server.
Greetings,
Stefan Winter
...
(11) [mschap] = noop (11) [eap-staff] = noop (11) [pap] = noop (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) (11) EXPAND %{Packet-Src-IP-Address} (11) --> 158.64.1.65 (11) if ( "%{Packet-Src-IP-Address}" == "158.64.1.229" ) -> FALSE (11) } # authorize = ok (11) Auth-Type = Accept, accepting the user ...
Are you sure it's definitely the pap module that's setting Auth-Type? If you comment it out, does the blank password still authenticate?
If so, a binary chop on your config to find the culprit may be helpful.
Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html