Jeff Smith <[EMAIL PROTECTED]> 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.

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to