date:20150924

[RADIATOR] Bugreport: OTP... PAP

2015-09-24 Thread Patrick Honing

Hello,

Due to the update of IOS on the iPhone and de OS on the Mac which uses TLSv1.2 
we upgraded our RADIUS setup.
The RADIUS-setup is used for our eduroam wireless network as well as for a 
VmWare VDI environment.

We are using a RedHat Enterprise Linux 5 environment for our RADIUS servers. We 
first updated the RHEL-delivered perl-Net-SSleay package with a self-build 
package at version 1.70 (RHEL version was 1.30). Secondly we updated Radiator 
from 4.08 to 4.15.

After this update our test mac (with new OS) could still not connect to the 
wireless network..The radiator debug log stated (inner authentication):

Mon Sep 14 14:15:47 2015: DEBUG: Handling request with Handler 
'TunnelledByTTLS=1', Identifier ''
Mon Sep 14 14:15:47 2015: DEBUG:  Deleting session for , 145.74.191.244,
Mon Sep 14 14:15:47 2015: DEBUG: Handling with Radius::AuthLDAP2:
Mon Sep 14 14:15:47 2015: DEBUG: Handling with EAP: code 2, 0, 16, 1
Mon Sep 14 14:15:47 2015: DEBUG: Response type 1
Mon Sep 14 14:15:47 2015: ERR: Could not load EAP module Radius::EAP_: Can't 
locate Radius/EAP_.pm in @INC (@INC contains: . 
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi 
/usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl 
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl 
/usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8 .) at (eval 
103) line 3.

Mon Sep 14 14:15:47 2015: DEBUG: EAP result: 1, Unsupported default EAP 
Response/Identity PAP
Mon Sep 14 14:15:47 2015: DEBUG: AuthBy LDAP2 result: REJECT, Unsupported 
default EAP Response/Identity PAP
Mon Sep 14 14:15:47 2015: INFO: Access rejected for : Unsupported default EAP 
Response/Identity PAP
Mon Sep 14 14:15:47 2015: DEBUG: Returned TTLS tunnelled Diameter Packet dump:
Code:   Access-Reject
Identifier: UNDEF
Authentic:  <183><170>L<23><10><234><237>x<9>@$m"<154><4>S
Attributes:
   Reply-Message = "Request Denied"

Because PAP was mentioned in the error, we removed (after trying a few dozen 
other things) PAP from out EAPtypes (was there historically and isn’t used 
anymore) as in:

# Handler voor TTLS

   
   Host ldap.han.nl 
   BaseDN dc=han,dc=nl
   SearchFilter (& (uid=%1) (nlHANsubscription=Wireless))
   HoldServerConnection
   EAPType MSCHAP-V2
   UsernameAttr uid
   PasswordAttr HASH
   UsernameMatchesWithoutRealm
   AuthDN uid=radius,,dc=mydomain,dc=com
   AuthPassword **
   

This fixes the problem with the mac, but keeps me wondering why PAP gives such 
a nasty error..

All fine.. Testing the Mac went fine so updating our production RADIUS servers… 
But this broke our VDI config:

# Handlers voor VDI

   
   PasswordPattern 99
   ChallengeHook file:"/etc/radius/scripts/otpsms.pl"
   AddToReplyIfNotExist State="OTP"
   StripFromReply Reply-Message
   AddToReply Reply-Message="Geef de code op die u via SMS ontvangen heeft"
   



   RewriteUsername s/^([^@]+).*/$1/
   RewriteUsername tr/A-Z/a-z/
   AuthByPolicy ContinueWhileAccept
   
   Host ldap.mydomain.com 
   BaseDN dc=mydomain,dc=com
   ServerChecksPassword
   HoldServerConnection
   
   
   PasswordPattern 99
   ChallengeHook file:"/etc/radius/scripts/otpsms.pl"
   AddToReplyIfNotExist State="OTP"
   StripFromReply Reply-Message
   AddToReply Reply-Message="Geef de code op die u via SMS ontvangen heeft"
   


We are using 2-factor authentication (with OTP via SMS) for VDI using the 
AuthOTP module. Our sms-scripts looks like this:

# This hook creates and SMS an one time password (OTP)

use IO::Socket;
use Net::LDAP;

sub {
   my ($self, $user, $p, $context) = @_;
   my $password = $self->generate_password();
   my $ldap = Net::LDAP->new('ldap.mydomain.com ') 
or die "$@";
   my $res = $ldap->search(
   base=> "dc=mydomain,dc=com",
   scope   => "sub",
   filter  => "(uid=$user)",
   attrs   => ['MOBILEPHONE']
   );
   if ($res->count) {
   my $ent = $res->entry(0);
   my $gsm = $ent->get_value("MOBILEPHONE");
   if ($gsm) {
   my $sock = IO::Socket::INET->new('smsserver.mydomain.com 
:9988') or die "Can't bind : $@\n";
   die unless ($sock->getline =~ "^SMS SERVER");
   print $sock "auth **\n";
   die unless ($sock->getline =~ "^OK:");
   print $sock “sendsms ".$gsm." Next response: ".$password."\n";
   die unless ($sock->getline =~ "^OK:");
   print $sock "exit\n";
   $context->{otp_password} = $password;
   }
   }
}

After update the result was always: 'OTP Authentication failed: ()’….

Digging into the code of Radiator (debug log didn’t give any hint) and adding 
some more debug messages to AuthOTP.pm revealed the problem.

A piece of code from AuthOTP.pm:

Re: [RADIATOR] Use FarmSize parameter

2015-09-24 Thread António Mendes


Hi Hugh, thanks for your answer.

The "father" process is consuming too much CPU due to the amount of 
requests, it's perfectly normal because we have a huge amount of 
clients. The Radiator's performance it's not a problem.
We need to move forward because we see that the hardware it's 
underused(one CPU core reaches several time 100% of use but the others 
are unused).  To avoid this problem and make use of all cores available 
we take a look of "Farmsize" feature, but like I said we are a bit 
worried about problems that could arise, like concurrency problems. So 
my question is if there are known problems in use the Farmsize, or do 
you advise to upgrade the configuration in another way.


Please note that we are thinking to use the Farmsize in accounting 
process, so the known authentication problems will not be a problem for us.


Best regards,

António Mendes

WIT Software | Software Engineer

This email was sent under WIT Software's Confidentiality Policy 



Às 07:38 de 24-09-2015, Hugh Irvine escreveu:

Hello Antonio -

I am curious to know why your “father” process is taking so much time?

Have you checked a trace 4 debug with LogMicroseconds enabled to see what 
exactly is taking the time?

If you send me a copy of your configuration file(s) directly, I will take a 
look and try to make some suggestions.

FarmSize can be used in some situations, but it can cause problems in other 
situations.

regards

Hugh



On 24 Sep 2015, at 00:40, António Mendes  
wrote:

Hello all,

We are running a scenario with an instance acting as a father and forwarding 
the traffic for children processes according to some parameters in request. We 
done that changing the init script and starting several instances of 
radiator(each one in a different port).

We are noticing that the father process are consuming too much processing resources and 
is only using one core, we would like to change this configuration to allow the 
distribution of load for all CPU cores available in the server and to do that we are 
thinking to use "FarmSize" and create several instances of father process.

Do you see any problem with this new approach(I'm a little bit worried about 
the write concurrency of log files)? Do you have any concern or recommendations?


Thanks
--
António Mendes

WIT Software | Software Engineer

This email was sent under WIT Software's Confidentiality Policy

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator


--

Hugh Irvine
h...@open.com.au

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER, SIM, etc.
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.



___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Use FarmSize parameter

2015-09-24 Thread Hugh Irvine

Hello Antonio -

I am curious to know why your “father” process is taking so much time?

Have you checked a trace 4 debug with LogMicroseconds enabled to see what 
exactly is taking the time?

If you send me a copy of your configuration file(s) directly, I will take a 
look and try to make some suggestions.

FarmSize can be used in some situations, but it can cause problems in other 
situations.

regards

Hugh

> On 24 Sep 2015, at 00:40, António Mendes  
> wrote:
> 
> Hello all,
> 
> We are running a scenario with an instance acting as a father and forwarding 
> the traffic for children processes according to some parameters in request. 
> We done that changing the init script and starting several instances of 
> radiator(each one in a different port).
> 
> We are noticing that the father process are consuming too much processing 
> resources and is only using one core, we would like to change this 
> configuration to allow the distribution of load for all CPU cores available 
> in the server and to do that we are thinking to use "FarmSize" and create 
> several instances of father process.
> 
> Do you see any problem with this new approach(I'm a little bit worried about 
> the write concurrency of log files)? Do you have any concern or 
> recommendations?
> 
> 
> Thanks
> -- 
> António Mendes
> 
> WIT Software | Software Engineer
> 
> This email was sent under WIT Software's Confidentiality Policy
> 
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator

--

Hugh Irvine
h...@open.com.au

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER, SIM, etc. 
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Use FarmSize parameter

2015-09-24 Thread Amândio Antunes Gomes Silva

Hi António (and the rest)!

From the Radiator 4.15 Reference Manual (Section 5)

5.7.43FarmSize

This optional parameter allows you to specify how many server instances to 
create in a server farm. A server farm is a set of identical Radiator servers, 
all monitoring the same RADIUS sockets. Incoming RADIUS requests are 
distributed among the child servers in the server farm. The main server acts as 
a supervisor, and restarts children that die or are terminated. Unix only. 
Defaults to 0, which means no server farm, and only a single instance of 
Radiator is run.

Hint: this parameter can be used to improve performance in some cases on 
platforms that support multiple cores and fork().

Caution: This parameter, and the use of server farms is not compatible with 
many EAP protocols, such as TLS, TTLS, PEAP etc. This is because such protocols 
rely in authentication state being held within each server process, and it is 
necessary for all the requests for such protocols to go to the same Radiator 
instance.

So you have to make sure that the platform where you have Radiator running on 
supports what’s mentioned in Hint.

Regards,

Cumprimentos,
Amândio Antunes Gomes da Silva
---
Serviços de Comunicações da Universidade do Minho
Campus de Gualtar, 4710-057 Braga - Portugal
Tel.: + 351 253 60 40 20, Fax: +351 253 60 40 21
email: aman...@scom.uminho.pt | 
http://www.scom.uminho.pt
---
This email is confidential. If you are not the intended recipient,
you must not disclose or use the information contained in it.
If you have received this mail in error, please tell us immediately
by return email and delete the document.
--
Este email é confidêncial. Se não é o destinatário do mesmo,
não deve nem revelar, nem usar o seu conteúdo.
Se recebeu esta mensagem por engano, por favor informe-nos
Imediatamente, devolvendo e apagando este email.





De: António Mendes [mailto:antonio.men...@wit-software.com]
Enviada: quarta-feira, 23 de setembro de 2015 15:40
Para: radiator@open.com.au
Assunto: [RADIATOR] Use FarmSize parameter

Hello all,

We are running a scenario with an instance acting as a father and forwarding 
the traffic for children processes according to some parameters in request. We 
done that changing the init script and starting several instances of 
radiator(each one in a different port).

We are noticing that the father process are consuming too much processing 
resources and is only using one core, we would like to change this 
configuration to allow the distribution of load for all CPU cores available in 
the server and to do that we are thinking to use "FarmSize" and create several 
instances of father process.

Do you see any problem with this new approach(I'm a little bit worried about 
the write concurrency of log files)? Do you have any concern or recommendations?


Thanks
--

António Mendes

WIT Software | Software Engineer

This email was sent under WIT Software's Confidentiality 
Policy
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Bugreport: OTP... PAP

2015-09-24 Thread vartiait

Hi,

On Thursday, 24 September, 2015 14:09, "Patrick Honing"  
said:
> 
> Mon Sep 14 14:15:47 2015: ERR: Could not load EAP module Radius::EAP_: Can't
> locate Radius/EAP_.pm in @INC (@INC contains: .
> /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl
> /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl
> /usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8 .) at (eval 
> 103)
> line 3.
> 
> Mon Sep 14 14:15:47 2015: DEBUG: EAP result: 1, Unsupported default EAP
> Response/Identity PAP
> 
> Because PAP was mentioned in the error, we removed (after trying a few dozen 
> other
> things) PAP from out EAPtypes (was there historically and isn’t used
> anymore) as in:
> 
> This fixes the problem with the mac, but keeps me wondering why PAP gives 
> such a
> nasty error..
> 

Thanks for bringing this up! Have to add a check there to prevent Radiator from 
trying to load an EAP class for a non-existing EAP type and log an error for 
wrong/non-supported EAP types in a configuration file :)

PAP is not an EAP type, supported EAP types are MD5, OTP, GTC, TLS, SecurID, 
LEAP, 
SIM, TTLS, AKA, PEAP, MSCHAP-V2, TNC, FAST, PAX, PSK, AKA-PRIME and PWD.

EAP-TTLS can transport PAP (plain simple RADIUS authentication), CHAP, MSCHAP, 
MSCHAPv2 (without 
EAP encapsulation) or any EAP method (including EAP-MSCHAPv2).

New Mac OS X 10.11. seems to use EAP-MSCHAPv2 within EAP-TTLS by default, 
whereas 
old versions used plain PAP or MSCHAPv2.

> All fine.. Testing the Mac went fine so updating our production RADIUS
> servers… But this broke our VDI config:
> 

could you send a trace 4 log file showing OTP challenge and response directly 
to me 
and I'll look at it?


BR
-- 
Tuure Vartiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.


___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Use FarmSize parameter

2015-09-24 Thread Hugh Irvine


Hi Antonio -

I would need to see your configuration file(s) before making suggestions.

If you send copies to me directly I will take a look.

regards

Hugh


> On 24 Sep 2015, at 18:10, António Mendes  
> wrote:
> 
> Hi Hugh, thanks for your answer.
> 
> The "father" process is consuming too much CPU due to the amount of requests, 
> it's perfectly normal because we have a huge amount of clients. The 
> Radiator's performance it's not a problem.
> We need to move forward because we see that the hardware it's underused(one 
> CPU core reaches several time 100% of use but the others are unused).  To 
> avoid this problem and make use of all cores available we take a look of 
> "Farmsize" feature, but like I said we are a bit worried about problems that 
> could arise, like concurrency problems. So my question is if there are known 
> problems in use the  Farmsize, or do you advise to upgrade the configuration 
> in another way.
> 
> Please note that we are thinking to use the Farmsize in accounting process, 
> so the known authentication problems will not be a problem for us.
> 
> Best regards,
> António Mendes
> 
> WIT Software | Software Engineer
> 
> This email was sent under WIT Software's Confidentiality Policy
> 
> Às 07:38 de 24-09-2015, Hugh Irvine escreveu:
>> Hello Antonio -
>> 
>> I am curious to know why your “father” process is taking so much time?
>> 
>> Have you checked a trace 4 debug with LogMicroseconds enabled to see what 
>> exactly is taking the time?
>> 
>> If you send me a copy of your configuration file(s) directly, I will take a 
>> look and try to make some suggestions.
>> 
>> FarmSize can be used in some situations, but it can cause problems in other 
>> situations.
>> 
>> regards
>> 
>> Hugh
>> 
>> 
>> 
>>> On 24 Sep 2015, at 00:40, António Mendes 
>>>  wrote:
>>> 
>>> Hello all,
>>> 
>>> We are running a scenario with an instance acting as a father and 
>>> forwarding the traffic for children processes according to some parameters 
>>> in request. We done that changing the init script and starting several 
>>> instances of radiator(each one in a different port).
>>> 
>>> We are noticing that the father process are consuming too much processing 
>>> resources and is only using one core, we would like to change this 
>>> configuration to allow the distribution of load for all CPU cores available 
>>> in the server and to do that we are thinking to use "FarmSize" and create 
>>> several instances of father process.
>>> 
>>> Do you see any problem with this new approach(I'm a little bit worried 
>>> about the write concurrency of log files)? Do you have any concern or 
>>> recommendations?
>>> 
>>> 
>>> Thanks
>>> -- 
>>> António Mendes
>>> 
>>> WIT Software | Software Engineer
>>> 
>>> This email was sent under WIT Software's Confidentiality Policy
>>> 
>>> ___
>>> radiator mailing list
>>> 
>>> radiator@open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
>> 
>> --
>> 
>> Hugh Irvine
>> 
>> h...@open.com.au
>> 
>> 
>> Radiator: the most portable, flexible and configurable RADIUS server 
>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
>> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
>> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
>> DIAMETER, SIM, etc. 
>> Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.
>> 
>> 
> 


--

Hugh Irvine
h...@open.com.au

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER, SIM, etc. 
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Bugreport: OTP... PAP

Re: [RADIATOR] Use FarmSize parameter

Re: [RADIATOR] Use FarmSize parameter

Re: [RADIATOR] Use FarmSize parameter

Re: [RADIATOR] Bugreport: OTP... PAP

Re: [RADIATOR] Use FarmSize parameter

6 matches

Site Navigation

Mail list logo

Footer information