Hi, Our wireless network currently authenticates and authorizes users via freeradius 0.8.1 with a custom module that talks to custom authentication and authorization servers. I'm upgrading the server side to freeradius 1.0.4. At the same time, the people who run the wireless network are switching to using EAP-PEAP with MS-CHAP v2. I'm fairly new to freeradius, but I have been spending a lot of time reading this list, the documents, the O'Reilly book, and experimenting with the server. So far I've been able to do PEAP authentications to the server via the users file. 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. 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. My thinking on this so far is that I might be able to use the Exec-Program-Wait atribute and/or the rlm_perl modules to call out to the custom servers, which have command-line interfaces. Ideally, I'd be able to do something like this: 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?" I can get back a yes/no answer and send an Access-Reject with an explanation, or continue on if they are authorized. (I don't think Exec-Program-Wait can help here since I understand it only gets called after the user is authenticated. I could make this check after and only if mschap returns success, though.) 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. 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. Thanks in advance! Jeff -- Jeff Smith Security Analyst - ITaP Identity & Access Management Purdue University W. Lafayette IN 47907-1408 Phone: 765-496-8285
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.
participants (2)
-
Alan DeKok -
Jeff Smith