On 11 Jan 2013, at 20:49, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 01/11/2013 08:32 PM, Arran Cudbard-Bell wrote:
Have you added nostrip for all the realms? The only way I can see it clobbering username is if stripping is enabled.
Isn't the problem the special request->username attribute?
It is, request->username appears to be pointing to the original User-Name pair instead of the new perl one.
AFAICT the pairmove code handles this specially ("fixup") but I'm not sure rlm_perl does the same?
Yes, unfortunately. That would have been a nice simple fix. https://github.com/FreeRADIUS/freeradius-server/blob/v2.x.x/src/modules/rlm_... @leggett If you don't mind rebuilding the server, could you change: https://github.com/FreeRADIUS/freeradius-server/blob/v2.x.x/src/main/modcall... And add: RDEBUG("Cached username is \"%s\", list username is \"%s\"", request->username->vp_strvalue, pairfind(request->packet->vps, PW_USER_NAME)->vp_strvalue); Just after modcall_single() Run it in debug mode and you'll see exactly where the username isn't being updated. List username and cached username should always be in sync up until the call to suffix, at which point the cached username should be stripped of the realm.
If that is the case, OP may find that putting the new username in an interim / temp variable then forcing update via unlang works:
authorize { ... myperl update request { User-Name := "%{The-Var}" } ... }
Yeah it should do. That calls radius_pairmove which has the magic update cache logic in it too. -Arran