On Aug 18, 2017, at 1:37 AM, John Horne <john.horne@plymouth.ac.uk> wrote:
However, I have updated freeradius to 3.0.15 (locally built RPM) on one of the servers. Whilst the local and visiting eduroam users are authenticating correctly, the majority of our own eduroam users authenticating to us via the NRPS servers now fail. The radius log shows (for example):
========== Thu Aug 17 23:16:20 2017 : ERROR: (7299) ERROR: Failing proxied request for user "abc@students.plymouth.ac.uk", due to lack of any response from home server 141.163.xxx.yyy port 1812
If NPS doesn't respond, NPS is the problem. :(
For the NRPS clients this occurs nearly 100% of the time. For some reason an occassional user will authenticate successfully. I have captured the debug output for a user who authenticated successfully on the 3.0.4 server, but then failed to authenticate on the 3.0.15 server. Although the last packet sent seemed acceptable, with no reply from the MS NPS server it is difficult to know what happened next.
Well, both 3.0.4 and 3.0.15 are compliant with all RADIUS standards. I suspect NPS isn't. I suspect that there are minor differences in packets which causes NPS to barf. I suggest looking at PCAPs (tcpdump / wireshark) to see what's different about the packets. Or, send me the PCAPs (off-list), and say which packets are the problems. I'll see if I can discover anything.
However, before that I thought I would ask here if anyone has any thoughts about this? Has anyone had a similar problem?
I've seen similar issues before with NPS. If NPS receives an attribute that it thinks is type "integer", but is instead 8 bytes long (i.e. not an integer), NPS will *drop the whole packet*. This behaviour is beyond stupid. I put text into RFC 6929 to address this exact problem: https://tools.ietf.org/html/rfc6929#section-2.8 I've also seen issues with other proprietary RADIUS servers that sometimes expect to see attributes in a particular order. One in particular had the idiotic behaviour of replying to "bad" packets by *echoing the bad packet back to the client*. I'm at a loss for how anyone ever thought that was a good idea. Alan DeKok.