unlang fails for some strange reason...

Stefan Winter stefan.winter at restena.lu
Mon May 7 11:13:59 CEST 2012


at a client's site, I have to some chopping off parts of User-Name,
pretty straightforward, but for some reason it doesn't work (2.1.12):

In inner-tunnel, authenticate, MSCHAPv2 for PEAP:

authenticate {

        Auth-Type MS-CHAP {

                if("%{Stripped-User-Name}" =~ /(....................).*/){
                                update request {
                                        SAMAccountName := "%{1}"
                else {
                        update request {
                                        SAMAccountName := "%{Stripped-User-Name}"

So, if the Stripped-User-Name is longer than 20 chars, chop it off and store it in SAMAccountName, otherwise, just store the full Stripped-User-Name in SAMAccountName.

SAMAccountName is defined in the dictionary as an internal attribute:

ATTRIBUTE SAMAccountName 3003 string

During run-time, the following strange thing happens...

# Executing group from file /etc/freeradius/sites-enabled/inner-tunnel
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/mschapv2
[eap] processing type mschapv2
[mschapv2] # Executing group from file /etc/freeradius/sites-enabled/inner-tunnel
[mschapv2] +- entering group MS-CHAP {...}
[mschapv2] ++? if ("%{Stripped-User-Name}" =~ /(....................).*/)
[mschapv2] expand: %{Stripped-User-Name} -> christian.test
[mschapv2] ? Evaluating ("%{Stripped-User-Name}" =~ /(....................).*/) -> FALSE
[mschapv2] ++? if ("%{Stripped-User-Name}" =~ /(....................).*/) -> FALSE
[mschapv2] ++- entering else else {...}
[mschapv2] expand: %{Stripped-User-Name} -> christian.test
[mschapv2] +++[request] returns reject
[mschapv2] ++- else else returns reject
[eap] Freeing handler
++[eap] returns reject
Failed to authenticate the user.

So... short User-Name, the else path is taken, Stripped-User-Name expands nicely... and then, the "update request" group returns reject?!?

I tried to use update control instead, which fails too, and used a non-internal attribute for that name as well. It just won't work.

Is that maybe one of the known quirks in 2.1.12? Would using the current stable branch work better?


Stefan Winter

Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20120507/e165d199/attachment.pgp>

More information about the Freeradius-Users mailing list