Ryon Day wrote: > Hello all, long-time reader, first time poster to this list. I've watched > many posters go down in flames on this list, so I'm going to try to learn > from their mistakes and be as precise as possible; I'm also going to make it > known at the outset that I have read all the documentation that I can get my > hands on and I am running FreeRADIUS -X to start it in debug mode!
It's easy to avoid "flames". Be honest, be clear, and follow instructions. > The authentication mechanism that we are using for the second-factor > authentication is a one-time password sent to the user via an out-of-band > mechanism. Therefore, this requires two different interactions with the > RADIUS server: > > 1: Access-Request: SSL-VPN -> FreeRADIUS. This sends the username (and > another piece of data that I am currently putting in the password field) to > the RADIUS server. > *At this point, I have written a JRadius component: > * On the SSL-VPN side I have PAP authentication selected. That is because > as above, I am using the password field to transfer another piece of data > (the delivery method) to RADIUS. > * It resides in the "authorize" stage of the "default" site in FreeRADIUS > * It looks the user up in LDAP (again) to obtain his/her E-Mail address > to send. It then sends the OTP to the e-mail address. This part works > perfectly! > * Then, I construct a new Access-Challenge packet in JRadius, creating a > new State and copying the initial Access-Request packet's identifier, and > return from the JRadius handler. This part also works perfectly. You can't create an Access-Challenge packet in jradius. You can only create a reply. If the user isn't accepted, the reply is automatically a reject. > 2: Access-Challenge: FreeRADIUS -> SSL-VPN device > This step is where the wheels are falling off the bus. FreeRADIUS does not > seem to want to send out my Access-Challenge packet; it automatically changes > it to an Access-Reject. I have even put another handler in the post-auth > reject handler to change it BACK to a Access-Challenge. At that point if I do > that, FreeRADIUS' debug mode reports that it is sending an Access-Request > packet to the IP address of the NAS (or my RADIUS test program)! You need to set the "request->reply->code = PW_ACCESS_CHALLENGE" for challenges to work. See rlm_example. It's just not set up to do manually created challenges. The reason is that 99.9999% of people get it wrong, and it's not necessary. > 3: Access-Request (original Using state and Packet ID so I can identify the > request on the back-end JRadius component) > * Compare passed OTP to stored OTP for that "session". Act accordingly. > * Obviously this step does not yet work! Does the SSL-VPN even support Access-Challenge? Some don't. > This leads me to believe that FreeRADIUS has a very rigid idea of what these > packets should be depending on auth method. Is there really no use case at > all for PAP where you would ever send an access challenge? Are there any > "dummy" auth methods that just, well, let me do whatever the hell I want? Is > it possible to implement a new Auth method like this? There are many cases where you can send an Access-Challenge. HOWEVER... most of them are mandated by the authentication method. EAP, MS-CHAP, etc. > Questions: > * Is there any way with current functionality, I can Implement a custom > challenge flow like the one I am describing? Yes. See rlm_example. You *can't* do it via unlang. > * Are there examples of this kind of functionality out there "in the wild" > that I can look at and use as a model? > * I greatly enjoy working with JRadius in spite of its occasional wonkiness, > but I can dust off my C if necessary. Is some sort of JRadius handler > combined with C FreeRADIUS mods possible? I do not mind writing code if it is > necessary, but of course I'd prefer not to if it's at all avoidable! (Is this > a question better posed to the dev list?) See rlm_example. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
