Stefan Winter wrote:

update request {
	User-Name := whatever
	User-Password := wh4t3v3r
}

in the pre-proxy section work? No need for a module then... And if I may
ask, why would you need to modify name and password for proxying? If it's
just about cutting out realms, there is an excellent realm module to do
that for you.

Yes, I can do that for static modifications, but in my case I have to
split the password and extract N bytes from it, which is a One-time
password for 2 factor authentication. I have to receive AUTH_ACK from
main radius server using the original password and then process the
second authentication stage with a 2 factor authentication manager using
that N bytes long OTP. (Connecting to 2FA server, sending OTP and
receiving result) This is why I need to do it in a module.


unlang can do WAY more than just static replacements. Use a regular 
expression.

if ( %{request:User-Password} =~ (.*)(......) ) update request {
	User-Password := %{2}
}

... or something close to that. My syntax may be imperfect, maybe someone can 
provide a more bullet-proof/correct one. 

This here is supposed to mean: if the password is at least 6 characters long, 
change the password so that it only is those last six characters (%{1} would 
be: only the first part, without the trailing OTP).
If it is less than six, this expression does nothing. I guess in your scenario 
you would want to discard those outright, because they don't contain a valid 
OTP. Add another rule for this case then. I'm ssuming your "N" to be = 6 
because that's a common length for OTPs. Put more/less dots at the end of the 
regexp if you have a different setup.

Thanks, You're right, unlang is a powerful tool. I just finished reading it's man page. it has very interesting features. (accessing run-time variables is wonderful). Your assumptions on my scenario is almost true and I do believe that your suggestion (regex in unlang) can completely remove any need for using a module in order to modify a request. However, In this specific scenario, I need much more further processing which should be done before I can decide to send a REJECT or ACCEPT. For example, I have to send extracted OTP to a remote authentication manager which it's answer would determine final authentication result.
In more detail it should be something like: open a socket, create a specific request packet, send it, wait for answer, parse the answer packet, and do further processing based on received answer from 2FA server.
Also, if we consider multi threading operation, there might be more issues that need to be taken care of.
Nevertheless, I believe even using a powerful tool like unlang cannot eliminate the need for an extra module. However, having a significant part of the whole job done by unlang this might only need a small python or perl module.

Now, any ideas on which of the user-password vp's I have to change ?


I'm trying to prepare you for the tough conclusion that you may not need any 
code changes here at all. That's why I changed the recipient to -users, 
not -devel.

Well, even if I just need to use a "update" in configuration files to do the job, I need to do it in right the place, I mean request, reply, proxy or proxy_reply. candidates for this one (password modification) are "request" and "proxy". I wonder if doing it in "proxy" can confuse freeradius for doing further process on it.

I know this is ugly. So, If I define my own attributes, is it necessary
for main RADIUS server (which we proxy to) to have modified dictionary
files ? or it will simply ignore those unknown attributes ?


It should. See RFC2865 section 5.26 and RFC5080 section 2.5 for details. But, 
to be honest, the pragmatically best approach is: TRY IT. Define a VSA, send 
it, and look what happens.

Thanks for references, according to these RFC's servers MUST ignore unknown VSA. However, I think you're completely right, I need to arrange a test case and see what would happen.

Again. Thanks for your great and helpful suggestions.

Greetings,

Stefan Winter


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