Jeff Smith <jsmith@purdue.edu> wrote:
The custom authentication module I referred to in the first paragraph basically re-implemented MS-CHAP v2 and talked to the custom servers on the back end. It would not be easy to wedge into the rlm_eap code.
Exactly. The rlm_eap code doesn't do MS-CHAP at *all*. Instead, it calls the mschap module.
Instead, I'd like to find a solution that makes the fewest possible (if any) modifications to stock freeradius, so we can track releases more closely. I would like to continue using the custom authentication and authorization servers.
If your existing module takes MS-CHAP attributes & does authentication, then you should be able to hack rlm_eap_mschapv2 to point to your module, rather than the mschap module. That should be a 1-line change to the source.
1) In the authorization phase, call out to the custom authorization server and ask a question like "Is this user who claims to be ``joe'' authorized to use the wireless service?"
Write a custom module.
2) In the authorization phase, also call out to the custom authentication server to get pack the NT-Password and add that to the value pairs in the check list in the request packet, so that when EAP-PEAP finally gets down to the MS-CHAP v2 part, the NT-password is available.
That should be easy. Just write a custom module. :)
I have been having a hard time getting my mind around the complexity of RADIUS and freeradius. It may be that I'm taking a completely wrong-headed approach here. If anyone on this list has any thoughts on how this could be done best, I'd appreciate hearing your ideas.
The design goal behind FreeRADIUS was to make things modular, so that you wouldn't have to worry about unrelated issues. Alan DeKok.