Re: unlang fails for some strange reason...

2012-05-09 Thread Stefan Winter 
Hello,

noone with a hint?

Stefan

On 07.05.2012 11:13, Stefan Winter wrote:
 Hi,
 
 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}
 }
 }
 mschap
 }
 
 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?
 
 Greetings,
 
 Stefan Winter
 
 
 
 
 -
 List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


-- 
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



signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: unlang fails for some strange reason...

2012-05-09 Thread Fajar A. Nugraha 
On Wed, May 9, 2012 at 2:45 PM, Stefan Winter stefan.win...@restena.lu wrote:
 Hello,

 noone with a hint?

Might not be the direct cause for your problem, but I'm pretty sure
you're not supposed to put unlang blocks inside authenticate section.
Or at least it's not recommended.

Try moving it to authorize section.

-- 
Fajar



 Stefan

 On 07.05.2012 11:13, Stefan Winter wrote:
 Hi,

 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}
                                 }
                 }
                 mschap
         }
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: unlang fails for some strange reason...

2012-05-09 Thread Alan DeKok 
Stefan Winter wrote:
 noone with a hint?

  Hmm...  the default return code for things in the authenticate
section is reject.  And the update sections just pass through the
*previous* return code.

  You might try this as a hack:

Auth-Type MS-CHAP {
ok
if (..) {
}
else {
}
mschap
}

  The ok at the start will over-ride the default reject

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

Re: unlang fails for some strange reason...

2012-05-09 Thread Stefan Winter 
Hi,

yet another subtlety I didn't know of... I'm checking with my client
whether either moving it to authorize or putting the ok in front will
do the trick.

I'll let the list know of the outcome so that the collective list
intelligence a.k.a. archive will have the answer for later.

Thanks,

Stefan

On 09.05.2012 09:56, Alan DeKok wrote:
 Stefan Winter wrote:
 noone with a hint?
 
   Hmm...  the default return code for things in the authenticate
 section is reject.  And the update sections just pass through the
 *previous* return code.
 
   You might try this as a hack:
 
 Auth-Type MS-CHAP {
   ok
   if (..) {
   }
   else {
   }
   mschap
 }
 
   The ok at the start will over-ride the default reject
 
   Alan DeKok.
 -
 List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


-- 
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



signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: unlang fails for some strange reason...

2012-05-09 Thread Stefan Winter 
Hi,

both methods worked: moving into authorize (but after calling the suffix
module, which sets Stripped-User-Name), and also the ok hack in
authenticate.

We chose to move to authorize, as it's more easily understandable.

Thanks for the help!

Greetings,

Stefan Winter

On 09.05.2012 11:17, Stefan Winter wrote:
 Hi,
 
 yet another subtlety I didn't know of... I'm checking with my client
 whether either moving it to authorize or putting the ok in front will
 do the trick.
 
 I'll let the list know of the outcome so that the collective list
 intelligence a.k.a. archive will have the answer for later.
 
 Thanks,
 
 Stefan
 
 On 09.05.2012 09:56, Alan DeKok wrote:
 Stefan Winter wrote:
 noone with a hint?

   Hmm...  the default return code for things in the authenticate
 section is reject.  And the update sections just pass through the
 *previous* return code.

   You might try this as a hack:

 Auth-Type MS-CHAP {
  ok
  if (..) {
  }
  else {
  }
  mschap
 }

   The ok at the start will over-ride the default reject

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


-- 
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



signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

unlang fails for some strange reason...

2012-05-07 Thread Stefan Winter 
Hi,

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}
}
}
mschap
}

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?

Greetings,

Stefan Winter

-- 
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



signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html