All, We're rolling out a password-expiry policy here, and it's been suggested that it would be helpful for the VPN to prompt a user to change their password, rather than just lock them out. The VPN is poptop on Linux, authing to FreeRadius, which current talks to winbind and then to our w2k3 servers but may be moving to proxy the final inner mschap to IAS (all the policy checks and interesting stuff will be staying on FreeRadius - but using FR2 and a proxy plus pool of home servers seems like to give us better failure and recovery characteristics when an AD controller goes away) When we MS-CHAP an expired account we get a MS-CHAP-Error packet in the reply as expected: Sending Access-Request of id 7 to 192.168.29.34 port 1812 Service-Type = Framed-User Framed-Protocol = PPP User-Name = "test" MS-CHAP-Challenge = 0xSNIP MS-CHAP2-Response = 0xSNIP Calling-Station-Id = 192.168.55.55 NAS-IP-Address = 192.168.54.54 NAS-Port = 0 Proxy-State = 0x3633 --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Access-Reject packet from host 192.168.29.34:1812, id=7, length=46 Proxy-State = 0x3633 MS-CHAP-Error = "\000E=648 R=0 V=3" ...however FreeRadius obeys the RFCs, and doesn't proxy the MS-CHAP-Error packet back to the radius client (pppd "radius.so" plugin) so my patches to pppd are unable to act on the error code. Am I wasting my time?
Hi,
Sending Access-Request of id 7 to 192.168.29.34 port 1812 Service-Type = Framed-User Framed-Protocol = PPP User-Name = "test" MS-CHAP-Challenge = 0xSNIP MS-CHAP2-Response = 0xSNIP Calling-Station-Id = 192.168.55.55 NAS-IP-Address = 192.168.54.54 NAS-Port = 0 Proxy-State = 0x3633 --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Access-Reject packet from host 192.168.29.34:1812, id=7, length=46 Proxy-State = 0x3633 MS-CHAP-Error = "\000E=648 R=0 V=3"
...however FreeRadius obeys the RFCs, and doesn't proxy the MS-CHAP-Error packet back to the radius client (pppd "radius.so" plugin) so my patches to pppd are unable to act on the error code.
how about using ulang to check for the MS-CHAP-Error - and if that code exists, create a new attribute that WILL be sent back to the radius client. ...one on which other bits of code could act. alan
Phil Mayers wrote: ...
rad_recv: Access-Reject packet from host 192.168.29.34:1812, id=7, length=46 Proxy-State = 0x3633 MS-CHAP-Error = "\000E=648 R=0 V=3"
...however FreeRadius obeys the RFCs, and doesn't proxy the MS-CHAP-Error packet back to the radius client (pppd "radius.so" plugin) so my patches to pppd are unable to act on the error code.
That is arguably something that could be included in an Access-Reject. Alan DeKok.
Alan DeKok wrote:
Phil Mayers wrote: ...
rad_recv: Access-Reject packet from host 192.168.29.34:1812, id=7, length=46 Proxy-State = 0x3633 MS-CHAP-Error = "\000E=648 R=0 V=3"
...however FreeRadius obeys the RFCs, and doesn't proxy the MS-CHAP-Error packet back to the radius client (pppd "radius.so" plugin) so my patches to pppd are unable to act on the error code.
That is arguably something that could be included in an Access-Reject.
Could you point me towards the place in the FR2 source code that does the RFC cleaning? I can't seem to find it.
Phil Mayers wrote:
Could you point me towards the place in the FR2 source code that does the RFC cleaning? I can't seem to find it.
raddb/attrs.access_reject seems to be the place. There's code in src/main/auth.c to remove all reply attributes on "too many logins", but that's different. Alan DeKok.
Alan DeKok wrote:
Phil Mayers wrote:
Could you point me towards the place in the FR2 source code that does the RFC cleaning? I can't seem to find it.
raddb/attrs.access_reject seems to be the place.
Ahh. The light dawns - I assumed it was hard-coded in like the rfc_clean() function in 1.1.7 and didn't even think to look elsewhere. Doh! Thanks - I'll re-rest with 2.0.3
participants (3)
-
A.L.M.Buxey@lboro.ac.uk -
Alan DeKok -
Phil Mayers