Re: [RADIATOR] Question about TACACS group assignment based on AD groups

[Hartmaier Alexander]

Hi Daniel,

we generate the Client config blocks using ClientListSQL from our NMS
database. The identifier is the hostname and we use the
OSC-Group-Identifier set to the support group name for further
distinguishment in the handlers.

We also add other metadata like OSC-Customer-Identifier for logging this
way.

Best regards, Alex


On 2016-09-08 07:12, Hugh Irvine wrote:
> Hello Daniel -
>
> You can use Identifiers in your Client clauses to indicate what sort of 
> device they are, then use those identifiers in your Handlers.
>
> Something like this:
>
> ……
>
> 
>   Identifier Firewall
>   …..
> 
>
> 
>   Identifier Firewall
>   …..
> 
>
> 
>   Identifier Switch
>   …..
> 
>
> 
>   Identifier Switch
>   …..
> 
>
> …..
>
> 
>   AuthByPolicy ContinueUntilAccept
>   AuthBy CheckReadOnlyAccessForFirewall
>   AuthBy CheckFullAccessForFirewall
> 
>
> 
>   AuthByPolicy ContinueUntilAccept
>   AuthBy CheckReadOnlyAccessForSwitch
>   AuthBy CheckFullAccessForSwitch
> 
>
>
> hope that helps
>
> regards
>
> Hugh
>
>
>
>> On 7 Sep 2016, at 23:28, daniel.herrm...@zv.fraunhofer.de wrote:
>>
>> Hi all,
>>
>> I want to use Radiator both for RADIUS and for TACACS for Cisco devices, 
>> including command level authorization. Based on some posts on this list I 
>> got both the active directory and the TACACS server module up and running, 
>> but struggle with the configuration of both.
>>
>> If I understand correctly, the TACACS module simply converts the TACACS 
>> authentication requests to radius requests and passes them to Radiator for 
>> ordinary execution. Authorization requests are handled within the TACACS 
>> module.
>>
>> My configuration currently looks as follows:
>>
>> --- begin ---
>> 
>>  # Define DC to connect to
>>  Hostdc-b.ad.x.com
>>
>>  # Identifier to use this AuthBy Clause later
>>  Identifier AuthByAD
>>
>>  # Administrative user used to perform LDAP queries
>>  AuthDN  
>> cn=Administrator,cn=Users,DC=ad,DC=x,DC=xxx,DC=de
>>  AuthPassword
>>
>>  # Where to search for users
>>  BaseDN  OU= User,DC=ad,DC=xxx,DC=xxx,DC=de
>>  ServerChecksPassword
>>
>>  # Add Check for group membership
>>  AuthAttrDef memberOf, ADGroup, check
>>
>>  # Reply should include the group names for further processing
>>  AuthAttrDef memberOf, ADGroups, reply
>>
>>  # There will be no default User
>>  NoDefault
>>
>>  # LDAP attribute to check the UserName on
>>  UsernameAttrsAMAccountName
>> 
>>
>> 
>> Port 49
>> AddToRequest NAS-Identifier=TACACS
>> GroupMemberAttr tacacsgroup
>>
>> AuthorizeGroup network_ro deny service=shell cmd=show 
>> cmd-arh=tech-support
>> AuthorizeGroup network_ro permit service=shell cmd=show cmd-arg=.*
>> AuthorizeGroup network_ro deny .*
>>
>> # This is for authorized users for full access. Place in lvl 15 
>> immediately, no restrictions apply
>> AuthorizeGroup full_access permit service=shell cmd\* {priv-lvl=15}
>> AuthorizeGroup full_access permit .*
>>
>> # Default deny to prevent accidents when something is misconfigured
>> AuthorizeGroup DEFAULT deny .*
>>
>> 
>>
>> # Include client definition
>> include %D/radius-clients.cfg
>> # Include Active Directory AuthBy Handler
>> include %D/authby-ad.cfg
>> # Include configuration for the built-in TACACS server
>> include %D/tacacs.cfg
>>
>> # TACACS Handler
>> 
>> AddToRequest ADGroup="CN=netadmin,C=ad,DC=,DC=,DC=de"
>> AuthBy AuthByAD
>>
>> # Try read-only access
>> # AddToRequest 
>> ADGroup="CN=netadmin-readonly,C=ad,DC=,DC=xxx,DC=de"
>> # AuthBy AuthByAD
>> 
>> --- end ---
>>
>> My problem now is how to tie both clues together in the handler. Ideally I 
>> would also like to distinguish based on the TACACS client which is asking. 
>> If it is a firewall (IPs known), then use command sets full_access_fw and 
>> firewall_ro based on AD groups.
>>
>> Basically I need something like this:
>>
>> -Firewall is TACACS client, and the user is member of group 
>> netadmin-security, return request with tacacsgroup=full_access_fw
>> -Switch is TACACS client, and the user is member of group netadmin, 
>> return request with tacacsgroup=full_access
>> -Firewall is TACACS client, and the user is member of group 
>> netadmin-security-ro, return request with tacacsgroup=firewall_ro
>> -Switch is TACACS client, and the user is member of group netadmin-ro, 
>> return request with tacacsgroup=network_ro
>>
>> How would I do this mapping?
>>
>> Many thanks and best regards
>> Daniel
>>
>>
>> ___
>> radiator mailing list
>> 

Re: [RADIATOR] Radiator and Load Balancer

[Hartmaier Alexander]

As a general network design we try to stay away from multihomed servers
as much as possible as the server admins lack networking/routing
know-how which leads to failing connectivity all the time.

Direct server return has its own share of problems which is why we don't
use it anymore but this is protocol dependent and might work for radius
which is udp.

When you configure the VIP as loopback on every radiator server and bind
radiator to this ip the reply packets should be sent from it.

Best regards, Alex


On 2016-07-28 00:48, xcorpse wrote:
> On 27/07/16 19:32, Robert Blayzor wrote:
>> DSR load balancing assumes the real servers know about the load balanced VIP 
>> and is generally configured on a loopback.
>>
>> The problem with this I think is that Radiator responds with a source 
>> address of where the packet leaves. (at least that’s been my experience). 
>> Most clients will probably ignore the response as it’s coming from a 
>> different address.
>>
>> With Radiator being Perl, I don’t think you can force Radiator to answer 
>> from a specific source address on the server.
> i've used radiator with dsr for some fairly large radius installs, works
> fine as long as you set it up correctly. the loopback alias or firewall
> packet mangling rules will make sure that the return packets are not
> ignored ...
>



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Questions regarding new release and current roadmap

[Hartmaier Alexander]

On 2016-07-05 12:39, Heikki Vatiainen wrote:
> On 1.7.2016 21.43, Hartmaier Alexander wrote:
>
>> On 2016-06-29 13:32, Nadav Hod wrote:
> Hello Alexander, hello Nadav,
>
>>> 2.1)  I haven't dealt with OCSP in the context of RadSec, but rather as a 
>>> scalable and faster alternative to CTL files in general when dealing with 
>>> any certificate. Many of our applications already support OCSP, and it 
>>> would be preferable to use OCSP with stapling than to perform the query 
>>> from the server each time a certificate needs to be validated.
>>>
>>> 2.2) EAP methods and LDAPS bindings.
> Thanks for the input. I took a note about LDAPS too. Radiator uses
> Net::LDAP which in turns IO::Socket:SSL which can do OCSP. It might be
> that Net::LDAP requires updates to enable OCSP for LDAPS or LDAP with
> Start TLS. We'll need to take a better look at this.
>
>> Async would fix all 'the radiator process is waiting for a DB query/LDAP
>> search/... that is slow or unresponsive and doesn't handle any other
>> requests for seconds' problem.
>> It doesn't require complicated multi-threading but some event look like
>> POE/IO::Async/... (please not AnyEvent!).
> We have done some work with EV but have not used it within Radiator.
>
> With Radiator there's the possibility of using SQL or LDAP libraries
> that support asynchronous operations which is probably a better fit with
> Radiator.
>
> Related to this, AuthBy RADIUS and its subclasses already support new
> return code (ASYNC) which allows an AuthBy to tell Handler that there is
> an asynchronous call in progress. In case of AuthBy RADIUS, when the
> reply is received, Handler can now move to the next AuthBy when there
> are multiple AuthBys. In other words, AuthBy RADIUS can work like the
> other AuthBys in a stack of AuthBys.
>
> Previously there were two choices:
> o the default which is that AuthBy RADIUS returns IGNORE when it has
> proxied the request
> o Synchronous flag which tells AuthBy RADIUS to wait for the reply
> before moving on.
That are great news! We have a radius proxy setup to several customer
radius servers which required hooks to do that without blocking.
Which version/patch introduced that feature? Seems I've missed it.
Would simplify our config quite a bit.
>
> Thanks for your input,
> Heikki
>
Thanks, Alex


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ServerTACACSPLUS logging improvements

[Hartmaier Alexander]

Hi Heikki,

On 2016-06-29 12:41, Heikki Vatiainen wrote:
> On 28.6.2016 11.24, Hartmaier Alexander wrote:
>
>> Tue Jun 28 08:18:50 2016: DEBUG: ServerTACACSPLUS: New connection from
>> 1.2.3.4:11422
>> Tue Jun 28 08:18:50 2016: ERR: Could not get peer name on
>> TacacsplusConnection socket: Transport endpoint is not connected
>> Tue Jun 28 08:18:50 2016: DEBUG: TacacsplusConnection disconnected from :
>>
>> As you can see is the last message lacking the source infos although
>> I've applied the latest patchset.
>> Any idea why?
> The 'Could not get peer name' log message was not changed at those
> patches yet. What was changed was the addition of the 'New connection'
> message.
>
> To get rid of need for Trace 4, the current patches now include slightly
> changed connection handling and updated logging. The peer IP and port
> are now saved from accept() and while getpeername() is still called, its
> function is only to check for connections that got immediately closed
> after they were opened.
>
> This check is depends on the timing, but it should catch those
> disconnects that were causing the 'Could not get peer name' log message.
> Otherwise the connections get closed by the normal processing.
>
> Or in brief: the log message is now more informative but the processing
> is otherwise the same.
Great, thanks!
>
> Note: the peer name log message is now logged as a WARNING instead of ERR.
I'd say that's a more appropriate log level, thanks!
>
>> But the 'New connection' message should be enough to find the bad boys
>> which seem to be two Cisco IOS routers.
> Hmm, that's interesting. Any reason why they do this?
With the 'New connection' message I was able to find the two IOS routers
causing the message. They weren't under our control (any more) but still
tried to establish TACACS+ sessions, possibly not using the correct key
with lead to those messages.
The admin of them deconfigured our Radiator servers and so the messages
are gone.

>
> Thanks,
> Heikki
>
Best regards, Alex


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Questions regarding new release and current roadmap

[Hartmaier Alexander]

On 2016-06-29 13:32, Nadav Hod wrote:
> Hi,
>
> 2.1)  I haven't dealt with OCSP in the context of RadSec, but rather as a 
> scalable and faster alternative to CTL files in general when dealing with any 
> certificate. Many of our applications already support OCSP, and it would be 
> preferable to use OCSP with stapling than to perform the query from the 
> server each time a certificate needs to be validated.
>
> 2.2) EAP methods and LDAPS bindings.
>
> 2.3) I agree that setting up multiple processes isn't a bottleneck, but it is 
> a bit of a hassle. It's a hassle you can automate, though.
>
> Thanks for the update :)
> 
> From: radiator-boun...@open.com.au [radiator-boun...@open.com.au] on behalf 
> of Heikki Vatiainen [h...@open.com.au]
> Sent: Wednesday, June 29, 2016 2:20 PM
> To: radiator@open.com.au
> Subject: Re: [RADIATOR] Questions regarding new release and current roadmap
>
> On 29.6.2016 12.16, Nadav Hod wrote:
>
>> 1) Any news on uploading the roadmap?
> No new news.
>
>> 2.1) OCSP + OCSP stapling. I've heard this is on the roadmap for the
>> near future.
> Yes, there was recently discussion about this related to RadSec support.
> What would your use case be? If it's for TSL based EAP methods, do you
> know what the stepling support is on the client side?
I'd love to have OCSP support too to not have the requirement for an
external script which downloads the crl files and converts them to pem
format.
>
>> 2.2) TLS resumption support by Session Tickets (RFC 5077). Another
>> option is to just wait for TLS 1.3 support although it would take
>> several years until most clients in an organization would support
>> TLS 1.3, if at all.
> Noted. For this feature too, would it be for EAP methods too or do you
> have something else in mind?
>
>> 2.3) Multithreading support for Windows Server (at the moment I'm
>> using a master service and splitting the handling of different
>> authentication methods to different Windows services).
> I don't think multithreading support is the way forward. What we are
> interested in doing is making it easier to run multiple instances that
> work together.
Async would fix all 'the radiator process is waiting for a DB query/LDAP
search/... that is slow or unresponsive and doesn't handle any other
requests for seconds' problem.
It doesn't require complicated multi-threading but some event look like
POE/IO::Async/... (please not AnyEvent!).
>
>> 2.4) A mature, flexible and robust web GUI, preferably one that can
>> manage distributed Radiator servers. The web GUI I'm using for 4.15
>> isn't much help for maintaining configuration and reading log files,
>> let alone multiple configuration files. Therefore I need to remote
>> desktop into the Radiator server in order to manage anything. This
>> is compounded further if you're using many Radiator servers.
> Centralised logging, and logging enhancements in general, is also
> something we're working on. There's also work done for interfaces that
> can enable building a web GUI, so the GUI does not have to be within
> Radiator itself.
>
> What comes to credential security, the credentials can be
> encrypted/obfuscated so that they are not in clear text format in the
> configuration file. There's initial support for that in the patches.
> However, we have not looked at separate products for credential storage.
>
> Thanks,
> Heikki
>
> --
> Heikki Vatiainen 
>
> 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
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Conditional Authby's

[Hartmaier Alexander]

Hi Julien,
I'd solve it by having two configurations, one for the static and one for the 
dynamic address assignment.
The order is irrelevant, I'd put the one that's matching more often first.
Configure the AuthByPolicy of the Handler to ContinueUntilAccept so both cases 
are checked until one returns accept.

So the static case is the easier one, just one AuthBy LDAP2 (note the case of 
AuthBy, you have it wrong in your original email) with a SearchFilter on 
Service-Type != DHCP (or Service-Type = Static or whatever value it has in your 
LDAP directory).

The dynamic case has the two AuthBy's (LDAP2 and DYNADDRESS) in an AuthBy GROUP 
with AuthByPolicy set to ContinueWhileAccept.

Best regards, Alex

On 2016-07-01 18:20, Julien CAVOIZY wrote:
Hello,

I am building a new authentication model for a new telco operator and I have a 
problem :
In the same Handler, I want to authenticate on a  and only if I get an 
attribute « service-type = DHCP » in the LDAP response it should go to a second  to allocate a dynamic IP.
I need that to do static IP allocation and fallback if not available to dynamic 
IP allocation.

How would you handle this with radiator ?

Thank you


Julien



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



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ServerTACACSPLUS logging improvements

[Hartmaier Alexander]

On 2016-06-24 13:57, Heikki Vatiainen wrote:
> On 24.06.2016 14:08, Hartmaier Alexander wrote:
>
>>> We also thought about further improvements for unexpectedly closed
>>> connections so that they can be logged and handled more easily. However,
>>> this is the first step before doing further changes.
>> We still get the 'Could not get peer name on TacacsplusConnection
>> socket: Transport endpoint is not connected' log message without
>> additional infos for which endpoint. Please don't add an additional
>> debugging message but improve the existing one!
> The error getpeername() sees is just that: the connection has gone away
> (while it was just established) so there's not much to improve this
> message anymore. The additional message I mentioned is available at
> trace 4 and it can stay because it's logged at the moment when the
> remote IP and port are first and surely available.
>
> However, maybe you could see what it shows on trace 4 now. The further
> changes in logging are planned to make unexpectedly closed connections
> logged so that are, for example, logged at INFO or WARNING level (trace
> 3 or 2). This should keep the log littering down, successfully opened
> connections are now logged unless debugging is enabled, while
> unexpectedly closed and unsuccessfully established connections are
> logged at higher log level.
>
> Maybe you could use trace 4 now to see where the shortlived client
> connections come from?

I've collected trace 4 logs:

Tue Jun 28 08:18:50 2016: DEBUG: ServerTACACSPLUS: New connection from
1.2.3.4:11422
Tue Jun 28 08:18:50 2016: ERR: Could not get peer name on
TacacsplusConnection socket: Transport endpoint is not connected
Tue Jun 28 08:18:50 2016: DEBUG: TacacsplusConnection disconnected from :

As you can see is the last message lacking the source infos although
I've applied the latest patchset.
Any idea why?
But the 'New connection' message should be enough to find the bad boys
which seem to be two Cisco IOS routers.
>
> Thanks for your comments,
> Heikki
>
Thanks, Alex


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ServerTACACSPLUS logging improvements

[Hartmaier Alexander]

Hi Heikki,

On 2016-06-21 12:58, Heikki Vatiainen wrote:
> On 13.06.2016 10:27, Hartmaier Alexander wrote:
>
>>> I also noticed that we can get the peer IP and port from accept directly
>>> instead of calling getpeername(). What is done now is to check accept
>>> return value for success and call getpeername() immediately after that.
>> I haven't seen that change in the patches, is it already in there so  I
>> can try it out?
> It's in the patches now. The IP address and port of the connecting
> client are now immediately logged after access instead in addition to
> calling getpeername() just a little later. The logging currently happens
> on trace 4 (debug) level.
>
> We also thought about further improvements for unexpectedly closed
> connections so that they can be logged and handled more easily. However,
> this is the first step before doing further changes.
We still get the 'Could not get peer name on TacacsplusConnection
socket: Transport endpoint is not connected' log message without
additional infos for which endpoint. Please don't add an additional
debugging message but improve the existing one!
>
> Thanks,
> Heikki
>
Thanks, Alex


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] OTP Authentication failed logging

[Hartmaier Alexander]

On 2016-06-23 17:04, Heikki Vatiainen wrote:
> On 16.06.2016 17:55, Hartmaier Alexander wrote:
>
>> I've encountered some 'OTP Authentication failed: ()' logs and digged
>> deeper where there coming from.
>> Line 104 returns if $result is undefined, line 107 if it's a true value
>> so the else tree is only hit if $reason is false in which case its value
>> is logged.
>> Is that's how you intended it?
> We took a look at this, and while the checks themselves look good, the
> log message is misleading. It looks like it is supposed to log an error
> or reason message. There might have been an error or reason message
> available earlier.
Will you change the log message?
>
> I'd say the best option is to log any failure reason in the OTP's
> VerifyHook if any special logs are needed.
We don't have a custom VerifyHook but use what comes with Radiator.
>
> Thanks for notifying us about this!
> Heikki
>



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] OTP Authentication failed logging

[Hartmaier Alexander]

Hi,
I've encountered some 'OTP Authentication failed: ()' logs and digged
deeper where there coming from.

In Radius/AuthOTP sub check_plain_password line 117 (4.16 with patches
1.1863):


else
 {
 my $result = $self->otp_verify($user, $submitted_pw, $p, $context);
 return ($main::REJECT, "OTP Authentication failed. Is OTP set
up properly?")
 unless defined $result;

 if ($result)
 {
 $p->{Handler}->logPassword($user, $submitted_pw, 'OTP', 1,
$p) if $p->{Handler};
 return ($main::ACCEPT);
 }:
 else
 {
 # Caution: this can happen if you are not running
 # as root.
 $p->{Handler}->logPassword($user, $submitted_pw, 'OTP', 0,
$p) if $p->{Handler};
 return ($main::REJECT, "OTP Authentication failed: ($result)");
 }
 }



Line 104 returns if $result is undefined, line 107 if it's a true value
so the else tree is only hit if $reason is false in which case its value
is logged.
Is that's how you intended it?

Cheers, Alex


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ServerTACACSPLUS logging improvements

[Hartmaier Alexander]

Hi Heikki,

On 2016-06-10 09:39, Heikki Vatiainen wrote:
> On 8.6.2016 11.28, Hartmaier Alexander wrote:
>
>>> Hmm, do you get these often? Also, does your configuration have FarmSize
>>> enabled? This error occurs very early after the new connection has been
>>> accepted. The code tries to figure out the address and port of the
>>> client, but getpeername call fails.
>> Yes, all the time. No FarmSize so far. So these are reverse dns lookups?
>> Can we disable them?
> These do not involve DNS. It's simply a socket function call that
> returns information about the socket.
>
> I tried reproducting this and noticed that a successful and normal TCP
> three-way handshake followed by RST causes this on Linux. On OS X the
> error is 'Invalid argument'.
>
> Do you have a monitoring program scanning for or monitoring TCP listen
> ports on your network? These scanners may be using the above method with
> their checks (normal open + RST to close).
No, that's from regular TACACS+ connection, I suspect NX-OS switches.
>
> I also noticed that we can get the peer IP and port from accept directly
> instead of calling getpeername(). What is done now is to check accept
> return value for success and call getpeername() immediately after that.
I haven't seen that change in the patches, is it already in there so  I
can try it out?
>
> Thanks,
> Heikki
>
Thanks, Alex


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ServerTACACSPLUS logging improvements

[Hartmaier Alexander]

On 2016-05-31 15:24, Heikki Vatiainen wrote:
> On 31.5.2016 12.57, Hartmaier Alexander wrote:
>
>>>> - Could not get peer name on TacacsplusConnection socket: Transport
>>>> endpoint is not connected
>>> Hmm, that's happening very early withing server tacacsplus, so there's
>>> no request, client, etc is available yet. Improvements here may be
>>> small, if any.
>> Than please at least add more information to the error message itself so
>> that at least the misbehaving client can be identified.
> Hmm, do you get these often? Also, does your configuration have FarmSize
> enabled? This error occurs very early after the new connection has been
> accepted. The code tries to figure out the address and port of the
> client, but getpeername call fails.
Yes, all the time. No FarmSize so far. So these are reverse dns lookups?
Can we disable them?
>
> I noticed the accept for the new connection is done slightly differenty
> than what the StreamServer class does, so I was thinking if this is
> something StreamServer does better in farm size environments.
>
> I'll see if there's anything more that can be logged too.
Thanks!
>
> Thanks,
> Heikki
>



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ServerTACACSPLUS logging improvements

[Hartmaier Alexander]

On 2016-05-30 11:31, Heikki Vatiainen wrote:
> On 27.5.2016 16.04, Hartmaier Alexander wrote:
>
>> The log messages emitted by ServerTACACSPLUS sadly lack all the standard
>> Radius attributes like Handler:Identifier, User-Name, Client-Identifier etc.
>> Is there a way to improve this situation?
> We can, and have already thought about, adding $p (the current request
> object, or sometimes $rp, the reply object) to a number of log messages
> that happen within message context. That is, where $p or $rp is available.
>
> The request/reply object should provide more information about handlers,
> clients, etc.
That would be great!
>
>> The log messages in question are:
>> - Could not get peer name on TacacsplusConnection socket: Transport
>> endpoint is not connected
> Hmm, that's happening very early withing server tacacsplus, so there's
> no request, client, etc is available yet. Improvements here may be
> small, if any.
Than please at least add more information to the error message itself so
that at least the misbehaving client can be identified.
>
>> - Authorization permitted for $USERNAME at $IPADDR, group $GROUPNAME,
>> args service=shell cmd*
> Should be possible, not completely sure yet though.
Access to $p and $rp would solve the problem here as well I guess.
>
>> But there are also non-ServerTACACSPLUS messages that don't include
>> those infos where it would be nice to know which Handler/AuthBy
>> trigggered them (those come from an AuthBy LDAP2, but which one?):
>> - Connecting to 1.2.3.4:636 1.2.3.5:636
>> - Connected to 1.2.3.4:636
>> - Attempting to bind to LDAP server 1.2.3.4:636
> These should be possible. Sometimes, for example with ClientList LDAP,
> the functions that log these are not called within message context. In
> other words, depending on the log caller, the call may or may not
> include the request that provides Client etc, information.
>
> I'll notify via this list when I have more information about these
>
> Thanks,
> Heikki
>
Thank you very much Heikki!!!


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] ServerTACACSPLUS logging improvements

[Hartmaier Alexander]

Hi,
I've finished forwarding all logs from all our Radiator instances to
Elasticsearch through syslog-ng (no need to install custom software on
the Radiator Servers) and RabbitMQ.

The log messages emitted by ServerTACACSPLUS sadly lack all the standard
Radius attributes like Handler:Identifier, User-Name, Client-Identifier etc.
Is there a way to improve this situation?

The log messages in question are:
- Could not get peer name on TacacsplusConnection socket: Transport
endpoint is not connected
- Authorization permitted for $USERNAME at $IPADDR, group $GROUPNAME,
args service=shell cmd*

But there are also non-ServerTACACSPLUS messages that don't include
those infos where it would be nice to know which Handler/AuthBy
trigggered them (those come from an AuthBy LDAP2, but which one?):
- Connecting to 1.2.3.4:636 1.2.3.5:636
- Connected to 1.2.3.4:636
- Attempting to bind to LDAP server 1.2.3.4:636

Thanks, Alex


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] help diagnosing failure to connect to LDAP

[Hartmaier Alexander]

Hi,
I'm using 'Debug 12' inside of  to troubleshoot TLS problems.
Have you set the port to 636 and UseSSL? UseTLS should really be named 
UseSTARTTLS because it's quite irritating otherwise.
You also need to configure the root CA (not intermeditate CA!) cert using 
SSLCAFile.

I haven't the need to run Radiator in the foreground, maybe I've missed the 
Net::LDAP errors in the past?!

Cheers, Alex

On 2016-05-11 18:42, Tuure Vartiainen wrote:

Hello,



On 11 May 2016, at 01:49, Jennifer Mehl 
 wrote:

I’m working on setting up a new RADIUS client/handler, and am having trouble 
diagnosing why connections from Radiator to an LDAP server are failing.

Using the ldapsearch command from the same system, using the same 
AuthDN/password yields a successful result.

I’m wondering if there is an error being kicked off somewhere from the LDAP or 
SSL Perl modules that I can’t see.  Or is there an open/broken connection to 
the LDAP server being cached somewhere that needs a “reset?”

I’ve turned on Trace 5 in radius.cfg and “Debug 255” in the AuthByLDAP2 clause, 
but not seeing a lot in the logs about the reason for the failure.




Perl’s LDAP library’s debug output, which is enabled with “Debug 255”,
can only be seen on a console when running Radiator on a foreground.

E.g.

$ perl radiusd -config /etc/radiator/radius.cfg -trace 4 -log_stdout -foreground


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



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Hartmaier Alexander]

Hi,

On 2016-03-30 15:10, Tuure Vartiainen wrote:
> Hi,
>
>> On 30 Mar 2016, at 14:55, Hartmaier Alexander 
>> <alexander.hartma...@t-systems.at> wrote:
>>
>> we use PEAP-TLS, EAP-PEAP as outer EAP type with EAP-TLS as inner.
>> Not sure if the outher EAP-PEAP adds any real security as the Radiator
>> cert is the same one for both types as it only hides the transmission of
>> the user cert which can be classified like a public key imho.
>>
> Ack.
Would you say that using PEAP-TLS for both wired and wireless auth is
overkill even when both are considered sniffable?

>
>> I've already tuned the EAPTLS_MaxFragmentSize to have as few roundtrips
>> as possible (1350 for the outer PEAP and 1300 for the inner EAP-TLS).
>>
> Yes, unfortunately beside that the only real option to minimize a delay of an 
> EAP authentication is to
> minimize the round-trips either by sending less certificate data or
> by using an EAP method with fewer rounds.
>
>> You see how I calculate the response_time in my email yesterday.
>>
> $p->{RecvTime} is set with a time of receive when an Access-Request is 
> received, so
>
> $message->{response_time} = Radius::Util::timeInterval(
> $p->{RecvTime},
> $p->{RecvTimeMicros}, Radius::Util::getTimeHires());
>
> will calculate a response time only for that Access-Request.
>
>
> When running Radiator with Trace 4 or 5, a total time for an EAP
> authentication can be seen in the log.
>
> E.g.
>
> Wed Mar 30 12:55:58 2016 816812: DEBUG: EAP Success, elapsed time 0.71221
>
> We’ll add a feature, which will allow the total time along with an on-demand
> timing to be used through %{...} special format in AuthLogs etc.
Thanks! Please inform me when it has landed in the patches.

>
>
> BR
BR


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Hartmaier Alexander]

Hi Tuure,
we use PEAP-TLS, EAP-PEAP as outer EAP type with EAP-TLS as inner.
Not sure if the outher EAP-PEAP adds any real security as the Radiator
cert is the same one for both types as it only hides the transmission of
the user cert which can be classified like a public key imho.

I've already tuned the EAPTLS_MaxFragmentSize to have as few roundtrips
as possible (1350 for the outer PEAP and 1300 for the inner EAP-TLS).

You see how I calculate the response_time in my email yesterday.

Best regards, Alex

On 2016-03-30 13:27, Tuure Vartiainen wrote:
> Hi,
>
>> On 30 Mar 2016, at 14:13, Hartmaier Alexander 
>> <alexander.hartma...@t-systems.at> wrote:
>>
>> yes this is the total auth time. Is one second a usual value for a
>> PEAP-TLS auth?
>>
> just out of curiosity, how do you calculate the total auth time?
>
> An EAP authentication takes around 4-10 round-trips depending on
> an EAP method and an amount of (certificate) data transferred.
>
> If you time the authentication from the receive time of the first 
> Access-Request
> to the final Access-Accept, your total time also includes transmission
> delays of those EAP round-trips between an EAP supplicant and Radiator.
>
> Does PEAP-TLS mean, that you are using EAP-PEAP with EAP-TLS as an innner EAP 
> method
> or EAP-PEAP with EAP-MSCHAPv2?
>
>
> BR



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] [***SPAM***] Re: Performance logging

[Hartmaier Alexander]

Hi guys,
yes this is the total auth time. Is one second a usual value for a
PEAP-TLS auth?

There is no backend lookup involved, only cert validation against
multiple CAs their local downloaded crl files.

Best regards, Alex

On 2016-03-30 12:05, Hugh Irvine wrote:
> Hello Alex -
>
> It depends on what you are looking at.
>
> EAP involves multiple RADIUS messages to and from the end user device and 
> Radiator.
>
> If you are looking at the overall response time from the initial RADIUS 
> Access-Request, through all of the EAP back and forth, to the ultimate 
> Access-Accept, there really is nothing you can do.
>
> If on the other hand you are looking only at the inner EAP request and the 
> associated authentication process, as Tuure says, any delays are likely to be 
> backend lookups.
>
> regards
>
> Hugh
>
>
>
>> On 30 Mar 2016, at 20:57, Tuure Vartiainen <varti...@open.com.au> wrote:
>>
>> Hi,
>>
>>> On 29 Mar 2016, at 11:53, Hartmaier Alexander 
>>> <alexander.hartma...@t-systems.at> wrote:
>>>
>>> I've copied the calculation code to my LogFormatHook code:
>>>
>>> $message->{response_time} = Radius::Util::timeInterval( \
>>> $p->{RecvTime}, \
>>> $p->{RecvTimeMicros}, Radius::Util::getTimeHires()); \
>>>
>>> I'd still prefer if that float was available with a placeholder variable.
>>>
>>> It shows what I was expecting, EAP authentication is slow.
>>> Any pointers where I can start optimizing the EAP auth performance?
>>>
>> hard to say without seeing your configuration and Trace 4 (DEBUG) log
>> of a single request including microseconds (LogMicroseconds).
>>
>> I assume that those timings are for the last Access-Request of
>> EAP authentication which produces either Access-Accept or Access-Reject.
>>
>> Usually most of the time goes to a user lookup from a backend.
>>
>>
>> BR
>> --
>> Tuure Vartiainen <varti...@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 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
>
> --
>
> 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.
>



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Hartmaier Alexander]

Thanks for the extensive infos!

I've copied the calculation code to my LogFormatHook code:

$message->{response_time} = Radius::Util::timeInterval( \
   $p->{RecvTime}, \
   $p->{RecvTimeMicros}, Radius::Util::getTimeHires()); \

I'd still prefer if that float was available with a placeholder variable.

Works like a charm:

[cid:part1.05080303.09030203@t-systems.at]

It shows what I was expecting, EAP authentication is slow.
Any pointers where I can start optimizing the EAP auth performance?

Thanks, Alex


On 2016-03-26 09:31, Heikki Vatiainen wrote:

On 03/24/2016 01:18 PM, Hartmaier Alexander wrote:



If you already calculate the response time can you please also expose it
via a special placeholder character?



In the current patches there's the possibility to log RecvTime and
RecvTimeMicros which are the second and microsecond of the time when the
request was received. These are variables stamped in the current request
and with the patches you can do %{ReplyVar:RecvTime} to e.g., log them.

What you could do is to log these two variables and the current time and
let the log processing system do the math.

Currently the response time calculation happens just before the reply is
sent, so it's not available earlier, for example, for authentication
logging.



I'd add this value to the AuthLog which goes via RabbitMQ to
Elasticsearch and can then be graphed in Kibana.



Sounds much like what our development team has worked on lately. A lot
of work has been done with Radiator logging recently.



We only struggle with Radiators' logging in one place: the global
logfile contains log messages from e.g. Hooks which are hard to
impossible to link to a specific request.
I'm in the process of getting more Radiator logs into Elasticsearch and
I'll look into if the Handler Identifier can be logged there as well.



As Alan mentioned, there's support in patches for linking/tracking
requests that are related to each other. When a request is received, a
tracing id is assigned to it. This id is then available for logging and
can be logged, for example, as a JSON attribute for log and
authentication log. See LogFormat.pm for an example.

It's also possible to use the Class attribute to bind authentication
with the subsequent accounting messages. For example, if the tracing id
is logged in the authentication log, you can use it later to view all
the log and accounting information related to that id. This will show
how the authentication and accounting was processed and what accounting
records were created for that particular session.

Binding with State is also supported. This allows tracing EAP
authentication sessions and other multi round authentications that use
State.

If you use the default log file format instead of e.g., JSON, you can
configure the tracing id to be appended in front of each line that is
logged into the log file. This allows using grep to quickly see all
lines that are related to a request.

This is still ongoing work, but the above should summarise what's been
done so far.

Any thoughts and ideas are welcome. I can certainly tell more about the
subject, but I tried to keep this message short instead of going into
full details immediately. The patches download page also has the list of
what's been added recently.

Thanks,
Heikki





*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Performance logging

[Hartmaier Alexander]

Hi,
that's neat!
If you already calculate the response time can you please also expose it
via a special placeholder character?

I'd add this value to the AuthLog which goes via RabbitMQ to
Elasticsearch and can then be graphed in Kibana.

We only struggle with Radiators' logging in one place: the global
logfile contains log messages from e.g. Hooks which are hard to
impossible to link to a specific request.
I'm in the process of getting more Radiator logs into Elasticsearch and
I'll look into if the Handler Identifier can be logged there as well.

Thanks, Alex

On 2016-03-24 08:27, Heikki Vatiainen wrote:
> On 24.3.2016 0.28, Hugh Irvine wrote:
>
>> Otherwise you can add your own custom time attributes in the current
>> request packet and post-process the logs to derive the deltas.
> Maybe this recent addition to 4.16 patches would be helpful too?
>
> Added a new global configuration parameter:
>
> ResponseTimeThreshold 10
>
> The value is a millisecond threshold for Radiator's response time. If
> the respose time is exceeded, a warning will be loggged.
>
> Here's an example of what it logs:
>
> Tue Mar 15 16:47:41 2016 577739: WARNING: Response time 16.804 ms for
> Access-Request id 236 exceeded 3 ms. (User: 'mikem', Client: 'DEFAULT'
> (default-client), Handler: '' (handler-identifier), Last AuthBy: 'FILE'
> (authby-identifier))
>
> Currently this is a global setting that's not turned on by default.
>
> Alex, you mentioned about logging each request with the processing time.
> Which logfile this should go into?
>
> There's work underway to log just the messages Radiator sends and
> receives. This is separate from the current logging and is more like
> what AuthLog does. What AuthLog logs are the successful and failed
> authentications. The message log will log all messages. The log format
> is configurable. At least text (similar to like trace 5 packet dump),
> pcapng and JSON will be supported.
>
> Thanks,
> Heikki
>



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] [***SPAM***] Re: Performance logging

[Hartmaier Alexander]

Hi Hugh,
is that a microsecond counter starting when the request is received?
Imho the wording is confusing, will it wrap around when the request 
takes more than one second?
How would I log the microseconds as integer for requests that take 
longer than one second?

Thanks, Alex

On 2016-03-23 10:33, Hugh Irvine wrote:
> Hello Alex -
>
> %s is the number of microseconds in the current second.
>
>  From section 5.2 of the Radiator 4.16 reference manual (“doc/ref.pdf”):
>
>   %s  Microseconds in the current second
>
> Note that the RADIUS protocol only defines times in seconds.
>
> regards
>
> Hugh
>
>
>> On 23 Mar 2016, at 19:44, Hartmaier Alexander 
>> <alexander.hartma...@t-systems.at> wrote:
>>
>> Hi,
>> I'd like to add the time it took to craft a response for each request to
>> the logs.
>> In the reference manual I only found %E which is 'The elapsed time in
>> seconds since the packet was received. Can be used to log
>> processing time for proxied packets etc.'.
>> For this logging I'd need at least milli- or better microseconds.
>> Did I overlook a placeholder for those or do they currently not exist?
>>
>> How do you guys monitor response time to prevent clients marking a
>> server as unresponsive because it takes it too long to send a response,
>> most of the time because of a backend like LDAP, SQL database or proxied
>> radius server being slow?
>>
>> Thanks, Alex
>>
>>
>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>> T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
>> Handelsgericht Wien, FN 79340b
>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>> Notice: This e-mail contains information that is confidential and may be 
>> privileged.
>> If you are not the intended recipient, please notify the sender and then
>> delete this e-mail immediately.
>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>> ___
>> 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

[RADIATOR] Performance logging

[Hartmaier Alexander]

Hi,
I'd like to add the time it took to craft a response for each request to
the logs.
In the reference manual I only found %E which is 'The elapsed time in
seconds since the packet was received. Can be used to log
processing time for proxied packets etc.'.
For this logging I'd need at least milli- or better microseconds.
Did I overlook a placeholder for those or do they currently not exist?

How do you guys monitor response time to prevent clients marking a
server as unresponsive because it takes it too long to send a response,
most of the time because of a backend like LDAP, SQL database or proxied
radius server being slow?

Thanks, Alex


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] EAP-TLS not getting client cert

[Hartmaier Alexander]

Hi,
I'd say the client doesn't trust the radiator certificate and stops the
EAP conversation.

Best regards, Alex

On 2016-01-18 12:30, Christian Kratzer wrote:
> Hi Sami,
>
> On Mon, 18 Jan 2016, Sami Keski-Kasari wrote:
>> Hello Christian,
>>
>> Usually this kind of behaviour is due to MTU problems.
>> There can be differences between different vendors for example how they
>> do tunnelling and how it affects to MTUs etc.
>>
>> Please try to adjust maximum TLS fragment size to see if it helps.
>>
>> Please see more at page 92
>> 5.21.39 EAPTLS_MaxFragmentSize
>> in ref.pdf.
> yes we already have that set to 500.
>
> Just for understanding EAPTLS_MaxFragmentSize would only affect what radiator 
> sends.  There is no way to limit the size of the fragements coming from the 
> ap.
>
> The trace4 logs stop exactly at the point radiator has completed sending of 
> it's certificate to the client.
>
> I would assume that I would at least see the first of the packets with the 
> client certificates.  If not this could perhaps also be an issue with the 
> network dropping incoming udp fragments and the os never being able to 
> reassemble incomplete packets.  I will have the customer check into that as 
> well.
>
> Greetings
> Christian
>
>



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] AuthBy LDAP2 to AD

[Hartmaier Alexander]

Great, thanks!

Regarding GC: we have a customer who has trusts to other ADs and had the
requirement to authenticate against all of them and it only worked when
using the Global Catalog and not specifying a BaseDN, maybe because it
is different for each for the trusted ADs and so the users would be
excluded from the results.

As I've created this config years ago I don't remember the details but
it's still running fine.

Best regards, Alex

On 2015-12-22 22:08, Heikki Vatiainen wrote:
> On 12/20/2015 09:49 PM, Hartmaier Alexander wrote:
>
>> @Heikki: could you add a section in the AuthBy LDAP2 which covers the
>> topic Microsoft Active Directory?
> I've made a ticket for this including these:
> - Global catalog ports
> - ServerChecksPassword - can't get user credentials from AD
> - AttrsWithBaseScope - for AD constructed attributes e.g., tokenGroups
> for getting group and nested group membership information
> - Differences with non-AD LDAP servers - anything else than the above?
>
> One thing I'd like to ask you about Global Catalog: If the Base DN is
> not empty, does it affect the search results? You wrote that it should
> be left empty, however, I so far I have thought it's fine to specify a
> Base DN.
>
> See for example this doc, and search for 'non-instantiated'. As I
> understand it, it says base DN that is empty or anything else is fine.
>
> https://technet.microsoft.com/en-us/library/how-global-catalog-servers-work(v=ws.10).aspx
>
> Thanks,
> Heikki
>



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] AuthBy LDAP2 to AD

[Hartmaier Alexander]

@Heikki: could you add a section in the AuthBy LDAP2 which covers the 
topic Microsoft Active Directory?


Thanks, Alex

On 2015-12-20 07:47, Joe Honnold wrote:
Got it all sorted.  Thanks for the pointers.  Here is what my working 
config for AD looks like.


Foreground
LogStdout
LogDir/var/log/radius
DbDir/etc/radiator
# User a lower trace level in production systems:
Trace 4
#
AuthPort1645
AcctPort1646


SecretIMNOTTELLLING




Debug 255
NoDefault
Host10.0.50.80 10.0.50.82
# Microsoft AD also listens on port 3268, and
# requests received on that port are reported to be
# more compliant with standard LDAP, so you may want to use:
Port 3268
AuthDNcn=ADAccount, OU=Unit3, DC=MS, DC=DOMAIN, DC=COM
AuthPasswordPLAINTEXTPASSWORD
BaseDN
PasswordAttr
ServerChecksPassword
UsernameAttr sAMAccountName
HoldServerConnection
FailureBackoffTime 0
AuthAttrDef MobileNumber,Callback-Number,request




On Dec 17, 2015, at 9:06 AM, Hartmaier Alexander 
<alexander.hartma...@t-systems.at 
<mailto:alexander.hartma...@t-systems.at>> wrote:


Hi,
sadly HoldServerConnection doesn't work for Active Directory for us.
Not sure if that's the source of your problem though.
If you search the Global Catalog (3268 for LDAP and 3269 for LDAPS) 
you can't specify a BaseDN, leave it empty!

Just
BaseDN

Best regards, Alex

On 2015-12-15 18:18, Joe Honnold wrote:

Hi.

I am working towards a config that does AD authentication with the 
addition of OTP.  I have started the AD config and have hit an issue 
that I can not seem to get around.

The log file states:

Tue Dec 15 10:34:24 2015: DEBUG: Radius::AuthLDAP2 REJECT: Bad
Encrypted password: UserJ [UserJ]

I have completed some research via the docs and internet searching 
but nothing has pointed me in the right direction yet.
Any input towards a resolution would be appreciated as I need this 
to work prior to adding the OTP settings to the config.


radius.cfg file
==
# ad-ldap.cfg
#
# Example Radiator configuration file for authenticating from
# Active Directory via LDAP2, possibly from a Unix host.
#
# This very simple file will allow you to get started with
# a simple LDAP authentication system from AD.
#
# We suggest you start simple, prove to yourself that it
# works and then develop a more complicated configuration.
#
#
# You should consider this file to be a starting point only
# $Id: ad-ldap.cfg,v 1.4 2015/06/02 19:37:27 hvn Exp $

Foreground
LogStdout
LogDir/var/log/radius
DbDir/etc/radiator
# User a lower trace level in production systems:
Trace 4
#
AuthPort1645
AcctPort1646

# You will probably want to add other Clients to suit your site.

SecretIMNOTTELLLING


# Authenticates users in the Organisational Unit called 'csx users'
# The user name coming from the NAS must match the sAMAccountName
# attribute of a user in that OU./ Users that are not in 'csx users'
# will not be able to log in.


Debug 255
NoDefault
Host10.0.50.80 10.0.50.82
# Microsoft AD also listens on port 3268, and
# requests received on that port are reported to be
# more compliant with standard LDAP, so you may want to use:
Port 3268
AuthDNcn=ADAccount, OU=Unit3, DC=MS, DC=DOMAIN, DC=COM
AuthPasswordPLAINTEXTPASSWORD
BaseDNDC=MS, DC=DOMAIN, DC=com
ServerChecksPassword
UsernameAttr sAMAccountName
HoldServerConnection
FailureBackoffTime 0
AuthAttrDef logonHours,MS-Login-Hours,check



==

Cleansed log dump
==
Tue Dec 15 10:34:24 2015: DEBUG: Packet dump:
*** Received from 10.0.100.8 port 58652 
Code:   Access-Request
Identifier: 188
Authentic:  <220><190><27><254>r<234><233>@<187>CR<161><231>C<241><4>
Attributes:
User-Name = "UserJ"
User-Password = <214><134>.<29><11>4<137><178><135>z<148>B<31>ivJ
Service-Type = Login-User
NAS-IP-Address = 10.0.100.8

Tue Dec 15 10:34:24 2015: DEBUG: Handling request with Handler '', 
Identifier ''
Tue Dec 15 10:34:24 2015: DEBUG:  Deleting session for UserJ, 
10.0.100.8,

Tue Dec 15 10:34:24 2015: DEBUG: Handling with Radius::AuthLDAP2:
Tue Dec 15 10:34:24 2015: INFO: Connecting to 10.0.50.80:3268 
10.0.50.82:3268

Tue Dec 15 10:34:24 2015: INFO: Connected to 10.0.50.80:3268
Tue Dec 15 10:34:24 2015: INFO: Attempting to bind to LDAP server 
10.0.50.80:3268
Tue Dec 15 10:34:24 2015: DEBUG: LDAP got result for CN=Joe 
User,OU=Unit1,OU=Unit2,DC=ms,DC=domain,DC=com
Tue Dec 15 10:34:24 2015: DEBUG: Radius::AuthLDAP2 looks for match 
with UserJ [UserJ]
Tue Dec 15 10:34:24 2015: DEBUG: Radius::AuthLDAP2 REJECT: Bad 
Encrypted password: UserJ [UserJ]
Tue Dec 15 10:34:24 2015: DEBUG: AuthBy LDAP2 result: REJECT, Bad 
Encrypted password
Tue Dec 15 10:34:24 2015: INFO: Access rejected for UserJ: Bad 
Encrypted password

Tue Dec 15 10:34:24 2015: DEBUG: Packet dump:
*** Sending to 10.0.100.8 port 58652 
Code:   Access-Reject
Identifier: 188
Authentic:  T<143>B*<10><203><165><29>6I<

Re: [RADIATOR] AuthBy LDAP2 to AD

[Hartmaier Alexander]

Hi,
sadly HoldServerConnection doesn't work for Active Directory for us.
Not sure if that's the source of your problem though.
If you search the Global Catalog (3268 for LDAP and 3269 for LDAPS) you can't 
specify a BaseDN, leave it empty!
Just
BaseDN

Best regards, Alex

On 2015-12-15 18:18, Joe Honnold wrote:
Hi.

I am working towards a config that does AD authentication with the addition of 
OTP.  I have started the AD config and have hit an issue that I can not seem to 
get around.
The log file states:

Tue Dec 15 10:34:24 2015: DEBUG: Radius::AuthLDAP2 REJECT: Bad Encrypted 
password: UserJ [UserJ]

I have completed some research via the docs and internet searching but nothing 
has pointed me in the right direction yet.
Any input towards a resolution would be appreciated as I need this to work 
prior to adding the OTP settings to the config.

radius.cfg file
==
# ad-ldap.cfg
#
# Example Radiator configuration file for authenticating from
# Active Directory via LDAP2, possibly from a Unix host.
#
# This very simple file will allow you to get started with
# a simple LDAP authentication system from AD.
#
# We suggest you start simple, prove to yourself that it
# works and then develop a more complicated configuration.
#
#
# You should consider this file to be a starting point only
# $Id: ad-ldap.cfg,v 1.4 2015/06/02 19:37:27 hvn Exp $

Foreground
LogStdout
LogDir /var/log/radius
DbDir /etc/radiator
# User a lower trace level in production systems:
Trace 4
#
AuthPort 1645
AcctPort 1646

# You will probably want to add other Clients to suit your site.

Secret IMNOTTELLLING


# Authenticates users in the Organisational Unit called 'csx users'
# The user name coming from the NAS must match the sAMAccountName
# attribute of a user in that OU./ Users that are not in 'csx users'
# will not be able to log in.


Debug 255
NoDefault
Host 10.0.50.80 10.0.50.82
# Microsoft AD also listens on port 3268, and
# requests received on that port are reported to be
# more compliant with standard LDAP, so you may want to use:
Port 3268
AuthDN cn=ADAccount, OU=Unit3, DC=MS, DC=DOMAIN, DC=COM
AuthPassword PLAINTEXTPASSWORD
BaseDN DC=MS, DC=DOMAIN, DC=com
ServerChecksPassword
UsernameAttr sAMAccountName
HoldServerConnection
FailureBackoffTime 0
AuthAttrDef logonHours,MS-Login-Hours,check



==

Cleansed log dump
==
Tue Dec 15 10:34:24 2015: DEBUG: Packet dump:
*** Received from 10.0.100.8 port 58652 
Code:   Access-Request
Identifier: 188
Authentic:  <220><190><27><254>r<234><233>@<187>CR<161><231>C<241><4>
Attributes:
User-Name = "UserJ"
User-Password = <214><134>.<29><11>4<137><178><135>z<148>B<31>ivJ
Service-Type = Login-User
NAS-IP-Address = 10.0.100.8

Tue Dec 15 10:34:24 2015: DEBUG: Handling request with Handler '', Identifier ''
Tue Dec 15 10:34:24 2015: DEBUG:  Deleting session for UserJ, 10.0.100.8,
Tue Dec 15 10:34:24 2015: DEBUG: Handling with Radius::AuthLDAP2:
Tue Dec 15 10:34:24 2015: INFO: Connecting to 10.0.50.80:3268 10.0.50.82:3268
Tue Dec 15 10:34:24 2015: INFO: Connected to 10.0.50.80:3268
Tue Dec 15 10:34:24 2015: INFO: Attempting to bind to LDAP server 
10.0.50.80:3268
Tue Dec 15 10:34:24 2015: DEBUG: LDAP got result for CN=Joe 
User,OU=Unit1,OU=Unit2,DC=ms,DC=domain,DC=com
Tue Dec 15 10:34:24 2015: DEBUG: Radius::AuthLDAP2 looks for match with UserJ 
[UserJ]
Tue Dec 15 10:34:24 2015: DEBUG: Radius::AuthLDAP2 REJECT: Bad Encrypted 
password: UserJ [UserJ]
Tue Dec 15 10:34:24 2015: DEBUG: AuthBy LDAP2 result: REJECT, Bad Encrypted 
password
Tue Dec 15 10:34:24 2015: INFO: Access rejected for UserJ: Bad Encrypted 
password
Tue Dec 15 10:34:24 2015: DEBUG: Packet dump:
*** Sending to 10.0.100.8 port 58652 
Code:   Access-Reject
Identifier: 188
Authentic:  T<143>B*<10><203><165><29>6I<4>0<129><234><251>9
Attributes:
Reply-Message = "Request Denied"

Tue Dec 15 10:34:29 2015: DEBUG: Packet dump:
*** Received from 10.0.100.8 port 58652 
Code:   Access-Request
Identifier: 188
Authentic:  <220><190><27><254>r<234><233>@<187>CR<161><231>C<241><4>
Attributes:
User-Name = "UserJ"
User-Password = <214><134>.<29><11>4<137><178><135>z<148>B<31>ivJ
Service-Type = Login-User
NAS-IP-Address = 10.0.100.8

Tue Dec 15 10:34:29 2015: INFO: Duplicate request id 188 received from 
10.0.100.8(58652): retransmit reply
Tue Dec 15 10:34:29 2015: DEBUG: Packet dump:
*** Sending to 10.0.100.8 port 58652 
Code:   Access-Reject
Identifier: 188
Authentic:  T<143>B*<10><203><165><29>6I<4>0<129><234><251>9
Attributes:
Reply-Message = "Request Denied"

Tue Dec 15 10:34:34 2015: DEBUG: Packet dump:
*** Received from 10.0.100.8 port 58652 
Code:   Access-Request
Identifier: 188
Authentic:  <220><190><27><254>r<234><233>@<187>CR<161><231>C<241><4>
Attributes:
User-Name = "UserJ"
User-Password = <214><134>.<29><11>4<137><178><135>z<148>B<31>ivJ
Service-Type = Login-User
NAS-IP-Address = 10.0.100.8

Tue Dec 15 10:34:34 2015: INFO: Duplicate request id 188 received from 
10.0.100.8(58652): 

[RADIATOR] dictionary.cisco-vpn bitmap type warning

[Hartmaier Alexander]

Hi guys,

when using the dictionary.cisco-vpn file we get the following warning on
startup:
WARNING: Attribute Cisco-VPN-WebVPN-HTML-Filter uses unknown type
'bitmap' on line 63

Please provide a fix in the patches, thanks!

Best regards, Alex


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Version 4.15 released - security fixes and enhancements

[Hartmaier Alexander]

Hi Heikki,
that's a great release!

I couldn't find info about CEF and JSON logging in the reference manual,
should be included at least as keywords with a pointer to the
'logformat.cfg' goodies file although I'd prefer having it in the main docs.

Is there a way to log the used TLS version and cipher to find out which
ones are in use before restricting it with the new EAPTLS_Protocols and
EAPTLS_Ciphers config options?

Best regards, Alex

On 2015-07-15 14:40, Heikki Vatiainen wrote:
 We are pleased to announce the release of Radiator version 4.15

 This version contains fixes for an EAP-MSCHAP-V2 and EAP-pwd
 vulnerability. Upgrade is recommended. Please review OSC security
 advisory OSC-SEC-2015-01 for more information:
 https://www.open.com.au/OSC-SEC-2015-01.html

 As usual, the new version is available to current licensees from:
 https://www.open.com.au/radiator/downloads/

 and to current evaluators from:
 https://www.open.com.au/radiator/demo-downloads

 Licensees with expired access contracts can renew at:
 https://www.open.com.au/renewal.html

 An extract from the history file
 https://www.open.com.au/radiator/history.html is below:

 -

 Revision 4.15 (2015-07-15)

   Selected fixes, compatibility notes and enhancements

 Fixes an EAP-MSCHAP-V2 and EAP-pwd vulnerability.
 OSC recommends all users to review OSC security advisory
 OSC-SEC-2015-01 to see if they are affected.
 https://www.open.com.au/OSC-SEC-2015-01.html

 perl-ldap-0.32 or better is required. Should be available in all current
 systems.

 EAP-pwd requires Crypt::OpenSSL::Bignum 0.06 or later from CPAN

 Configurable TLS version and ciphersuite selection for TLS based EAP and
 stream modules

 CRL checks for the entire certificate chain can now be enabled

 Included Gossip framework with Redis based implementation

 Support for Gossip when communicating next hop proxy failures between
 Radiator instances

 Shared duplicate cache for a more simple server farm configuration

 Windows Event log support

 Custom format support for logs, authentication logs and accounting logs.
 CEF and JSON included

 Support for IEEE 802.1AE, also known as MACsec

 All AuthBys now support PostAuthHooks

 Various binary modules are now available from OSC and were removed from
 the Radiator distribution



   Detailed changes

 Added VENDOR STI (Server Technology Inc.) 1718 and multiple STI VSAs to
 dictionary. Contributed by Garry Shtern.

 Added VENDOR PacketDesign 8083 and VSAs PacketDesign-UserClass and
 PacketDesign-FTP to dictionary. Contributed by Garry Shtern.

 Added SN-Software-Version to dictionary. Reported by Bruno Tiago Rodrigues.

 Changed type of VENDORATTR 3076 Cisco-VPN-DHCP-Network-Scope in
 dictionary.cisco-vpn from text to ipaddr. Reported by Kilian Krause.

 Dictionary updates: Added H3C proprietary values H3C-SSH and H3C-Console
 for Login-Service. Changed Lancom LCS-Mac-Address type from string to
 hexadecimal. Added H3C-Priority. All reported by Philip Herbert.

 Zero length writes are now skipped in Stream.pm write_pending() used by
 RadSec, Diameter, SIGTRAN and other stream protocols. SCTP does not
 support 0 length syswrites on all platforms and may close the socket if
 zero length write is done.

 Added VENDOR Airespace 14179 VSAs 7-11 and 13-16 to dictionary.

 AuthBy GROUP now updates current AuthBy for %{AuthBy:parmname}. When
 AuthBy GROUP is used, this special formatting now gets the parameter
 value from the current AuthBy within the group instead of the AuthBy
 GROUP itself.

 Updated VENDOR 1991 Foundry VSAs in dictionary. foundry-privilege-level
 is now a synonym for brocade-privilege-level. Added a number of foundry
 VSAs.

 LDAP Version now defaults to 3 instead of 2. Updated a number of LDAP
 configuration example files in goodies to reflect this change.

 Ldap.pm now uses the LDAP object's disconnect method, instead of closing
 the socket directly.

 AuthBy LDAP2 and AuthBy LDAPDIGIPASS now use escape_filter_value
 provided by Net::LDAP::Util instead of escapeLdapLiteral in Ldap.pm
 Ldap.pm escapeLdapLiteral is now deprecacted and perl-ldap-0.32 or
 better is required.

 RefreshPeriod in ClientListSQL and ClientListLDAP now support special %
 formatting. Suggested by Bengi Sağlam.

 Updated VENDOR 2011 Huawei VSAs in dictionary. Huawei-Input-Basic-Rate
 is now an alias for Huawei-Input-Peak-Rate. Huawei-Output-Basic-Rate was
 changed similarly. Some of the attribute numbers appear to have
 different names and types between different devices. Huawei-User-Type,
 Huawei-MIP-Agent-MN-Flag and Huawei-Requested-APN are now aliases but
 aliasing may be handled with separate dictionary files in the future.
 Huawei-HW-Portal-Mode was renamed to Huawei-Portal-Mode.

 WiMAX dictionary updates: changed WiMAX-Session-Termination-Capability
 type to integer and added one value: Dynamic-Authorization. Changed
 WiMAX-PPAQ TLV Quota-Identifier type to binary. WiMAX subattributes
 within 

Re: [RADIATOR] Radiator Version 4.15 released - security fixes and enhancements

[Hartmaier Alexander]

On 2015-07-16 15:07, Heikki Vatiainen wrote:
 On 16.7.2015 13.42, Hartmaier Alexander wrote:

 I couldn't find info about CEF and JSON logging in the reference manual,
 should be included at least as keywords with a pointer to the
 'logformat.cfg' goodies file although I'd prefer having it in the main docs.
 Good point. I'll see that CEF and JSON will be mentioned in ref.pdf

 The configuration sample file 'logformat.cfg' is mentioned where
 LogFormatHook for Log FILE and AuthLog FILE are described. It's also
 mentioned where AcctLogFileFormatHook for accounting messages is described.

 The configuration sample shows how to use the new module
 Radius/LogFormat.pm. This module includes CEF and JSON authentication
 log formatting and JSON accounting log formatting.

 There's also an example of how to use a custom module, possibly modified
 from Radius/LogFormat.pm, to change the formatting or add new formats.
I know because I was the one who requested the feature and wrote the Log
module before you added the hook ;)


 Is there a way to log the used TLS version and cipher to find out which
 ones are in use before restricting it with the new EAPTLS_Protocols and
 EAPTLS_Ciphers config options?
 I think the ciphers are the ones that can be listed with 'openssl
 ciphers -v' these depend on the SSL/TLS library. Older OpenSSL versions
 seem to have quite different set of ciphers than the most recent
 LibreSSL for example.

 In other words the ciphers could be listed by radiusd, but you can also
 see them from the command line. Also, new DEBUG level log message was
 added to show which Net::SSLeay version and SSL/TLS libary is used to
 make sure radiusd uses what you expect it to.

 The protocols also depend on what's compiled in the SSL/TLS library. I
 think the recent LibreSSLs do not have SSLv3 support anymore. Are you
 thinking about printing the available SSL/TLS versions before
 restricting them? Note that for TLS based EAPs, TLSv1 is the minimum so
 SSLv3 is not possible which means what you can use is TLSv1 or better.
Yes I know. What I'd like to have is a way to *log* the actual chosen
cipher per EAP-TLS connection, ideally in the AuthLog file.


 Thanks,
 Heikki

Cheers, Alex


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] New features and changes in the next Radiator release

[Hartmaier Alexander]

On 2015-06-19 09:16, Heikki Vatiainen wrote:
 On 06/18/2015 01:01 PM, Hartmaier Alexander wrote:

 Especially the work on sharing state between instances, we had problems
 with tacacs sessions from Cisco WLCs that authorize on a different
 server than the authentication happened which lead to non-working user
 rights.
 Thanks for your comments. Does WLC do this when it has been configured
 with multiple TACACS+ servers? That is, it does not try to use the same
 server for all requests that belong to the user's session even if that
 server is responding?
Yes, sadly.

 I'll make a note that this is one case where state sharing would be
 needed for TACACS+.

 Regarding logging I'd love to see support for noSQL databases and
 messages queues like RabbitMQ and Elasticsearch which can be used as log
 target.
 I would be interested to hear your and others' views about how to work
 with different noSQL DBs and how they should be used with Radiator.

 For example, there has been interest in Apache Cassandra for AuthBy CQL,
 AuthLog CQL, session database etc.

 With SQL we can use DBI to cover all the SQL databases. With noSQL it
 seems each noSQL server needs its own interface. Or in other words, if
 support for them is done one by one, which noSQL servers should be
 supported first? For example MongoDB has good Perl support and is widely
 used, but CQL seems to be a good, maybe better, match for this type of
 application. Amazon Dynamo DB is, of course, restricted to AWS (and has
 been used by us in one custom setup).

 What comes to Elasticsearch, would using Logstash to read the files
 while they are generated do the trick, at least for now?
We use a Perl daemon based on Message::Passing to read from a special
fifo file generated with mkfifo and enqueue the log messages in RabbitMQ
from where they are stored in Elasticsearch by another damon on the
central log servers.


 About message queues, are you thinking about RabbitMQ, or the other MQs,
 for logging only? I mentioned control plane in my previous message, but
 we are also thinking about data plane to have something to distribute
 requests between different instances. Pushing logs in a MQ could also be
 done too.

 Using both control and data plane is interesting because it allows for
 more automatic and easier set up of multiple instances as opposed to
 creating configuration files manually. A queue can be monitored to see
 if the instances are starting to have problems processing all the
 requests. If this happens, the queue management can log the problem or
 start additional instances. Other useful features include log routing,
 as you mentioned, maybe as a control plane service too.
That would be a great improvement over the current blocking nature of
Radiator which would allow to scale it with multiple cores much better!
I can recommend POE which we use in our inhouse NMS since over ten years
without an issue.

 Thanks,
 Heikki

Best regards, Alex


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] EAP TTLS authentication problem

[Hartmaier Alexander]

Usually this occurs if the EAPTLS_MaxFragmentSize is set too large in regards 
to the smallest MTU of the path the Radius packets take.

1000 is a low value for an Ethernet infrastructure with a MTU of 1500 but you 
might have tunnels or some other media with a smaller MTU in your path.

Another possibility is that the client doesn't trust the radius server 
certificate which will cause it to stop further processing too.

Best regards, Alex

On 2015-05-08 13:54, Bengi Sağlam wrote:
Hi all,

I have a problem with the EAP TTLS authentication. My current configuration 
file as following:


SessionDatabase SQL
   Identifier Employee
   DBSource
dbi:Pg:dbname=%{GlobalVar:dbname};host=%{GlobalVar:host};port=%{GlobalVar:port}
   DBUsername %{GlobalVar:dbusername}
   FailureBackoffTime 2
   Timeout 10
   AddQuery .
   DeleteQuery begin work; \
  …...
   ClearNasQuery……….
/SessionDatabase

Realm DEFAULT
   SessionDatabase Employee
   PreProcessingHook  sub { \
   my $p = ${$_[0]};\
   my $aref = $p-{Client}-{DupCacheOrder}[0]-{Attributes};\
   my %h ;\
   foreach my $pair ( @$aref ) { $h{$pair-[0]} = $pair-[1] } ;\
   ${$_[0]}-add_attr('Threshold',8);\
   ${$_[0]}-add_attr('Interim-Update',300);\
   }
   AuthBy SQL
 DBSource
dbi:Pg:dbname=%{GlobalVar:dbname};host=%{GlobalVar:host};port=%{GlobalVar:port}
 DBUsername %{GlobalVar:dbusername}
 FailureBackoffTime 2
 NoDefault
 Timeout 10

 AuthSelect SELECT …..
   AuthColumnDef 0, User-Password, check
   AuthColumnDef 1, User-Name, check
   AuthColumnDef 2, Max-Daily-Session, check
   AuthColumnDef 3, Session-Timeout, reply
   AuthColumnDef 4, WISPr-Bandwidth-Max-Down, reply
   AuthColumnDef 5, WISPr-Bandwidth-Max-Up, reply
   AuthColumnDef 6, Idle-Timeout, reply
   AuthColumnDef 7, ChilliSpot-Bandwidth-Max-Up, reply
   AuthColumnDef 8, ChilliSpot-Bandwidth-Max-Down, reply

   AcctTotalSinceQuery.

 HandleAcctStatusTypes Start, Alive ,Stop

 AcctSQLStatement …...

 AcctSQLStatement ….

 AcctSQLStatement DELETE FROM RADONLINE WHERE USERMAC= 
'%{Calling-Station-Id}' AND NASID ='%{NAS-Identifier}' AND 'Stop' 
='%{Acct-Status-Type}'

 EAPType TTLS
 EAPTLS_PrivateKeyPassword ***
 EAPTLS_CAFile 
/usr/local/etc/radiator/%{GlobalVar:nodename}/cert/DigiCertCA.crt
 EAPTLS_CertificateFile 
/usr/local/etc/radiator/%{GlobalVar:nodename}/cert/hotspot.crt
 EAPTLS_CertificateType PEM
 EAPTLS_PrivateKeyFile 
/usr/local/etc/radiator/%{GlobalVar:nodename}/cert/priv.pem
 EAPTLS_MaxFragmentSize 1000
 EAPTTLS_NoAckRequired
 AutoMPPEKeys
   /AuthBy
/Realm



Radiator log file:




Fri May  8 13:16:56 2015 309744: DEBUG: Packet dump:
*** Received from 217.124.187.38 port 49158 

Packet length = 220
01 10 00 dc 28 c1 88 9a 42 e6 ca 29 0e 35 31 8b
44 5d 5c b5 01 09 6d 61 72 71 75 65 73 04 06 d9
7c bb 26 05 06 00 00 00 00 20 13 39 43 2d 31 43
2d 31 32 2d 43 45 2d 34 31 2d 43 43 3d 06 00 00
00 13 1f 13 30 34 3a 34 36 3a 36 35 3a 36 36 3a
44 36 3a 30 44 1e 13 39 43 3a 31 43 3a 31 32 3a
43 45 3a 34 31 3a 43 43 06 06 00 00 00 01 0c 06
00 00 04 4c 4f 0e 02 01 00 0c 01 6d 61 72 71 75
65 73 1a 17 00 00 39 e7 05 11 45 6d 70 6c 65 61
64 6f 73 5f 53 49 4c 41 4e 1a 19 00 00 39 e7 06
13 39 63 3a 31 63 3a 31 32 3a 63 65 3a 34 31 3a
63 63 1a 18 00 00 39 e7 0a 12 69 6e 73 74 61 6e
74 2d 43 45 3a 34 31 3a 43 43 50 12 e8 17 50 88
22 68 0a 6c 67 3c 68 3f f9 c1 c1 a3
Code:   Access-Request
Identifier: 16
Authentic:  (193136154B230202)1451139D]\181
Attributes:
   User-Name = marques
   NAS-IP-Address = 217.124.187.38
   NAS-Port = 0
   NAS-Identifier = 9C-1C-12-CE-41-CC
   NAS-Port-Type = Wireless-IEEE-802-11
   Service-Type = Login-User
   Framed-MTU = 1100
   EAP-Message = 210121marques
   Aruba-Essid-Name = Empleados_SILAN
   Aruba-Location-Id = 9c:1c:12:ce:41:cc
   Aruba-AP-Group = instant-CE:41:CC
   Message-Authenticator = 23223P136h10lgh?249193193163
   Called-Station-Id = 9C-1C-12-CE-41-CC
   Calling-Station-Id = 04_46_65_66_D6_0D

Fri May  8 13:16:56 2015 310184: DEBUG: Handling request with Handler 
'Realm=DEFAULT', Identifier ''
Fri May  8 13:16:56 2015 310483: DEBUG: Employee Deleting session for marques, 
217.124.187.38, 0
Fri May  8 13:16:56 2015 311407: DEBUG: do query to 
'dbi:Pg:dbname=radius;host=silandb;port=5432': 'begin work; INSERT INTO 
DEVICES(MAC,DEVICEMODEL,DEVICEOS,PASSWORD,LOCALE,CREATED,MODIFIED) 
VALUES(COALESCE(NULLIF('04_46_65_66_D6_0D',''),''),1,1,RANDOM_STRING(24),'s:2:es',EXTRACT(EPOCH
 FROM NOW())::INT,EXTRACT(EPOCH FROM NOW())::INT); INSERT INTO 
DEVICES_LOCATIONS(MAC,LOCATIONID,CREATED,MODIFIED) 

[RADIATOR] sub-second precision logging

[Hartmaier Alexander]

Hi guys,
I wasn't able to find any information in the manual on subsecond
precision logging when you want to define your own timestamp format with
the placeholders shown in section 5.3.
LogMicroseconds in a Log FILE block with LogFormatHook doesn't seem to
have an effect on %S and there is no placeholder for the micro- or
nanoseconds either.
Addition of a placeholder would be very welcome.

Thanks  Best regards, Alex


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] ODBC Connection Error

[Hartmaier Alexander]

If you try to connect to an Oracle database install Oracle Instantclient
and DBD::Oracle.

On 2015-03-12 10:18, Mohammed Alhaj Ali wrote:
 Hi Hugh, but this lib file actually is there, and when I try to connect with 
 other DBD ie. Oracle it also failed, how can I check if there any wrong with 
 perl and  perl modules..

 Thank you!



 -Original Message-
 From: Hugh Irvine [mailto:h...@open.com.au]
 Sent: Thursday, March 12, 2015 11:17 AM
 To: Mohammed Alhaj Ali
 Cc: radiator@open.com.au
 Subject: Re: [RADIATOR] ODBC Connection Error


 Hello -

 As the error message says, this shared library is not found:  
 '/usr/lib/libsqora.so.11.1’

 A quick Google search on Can't open lib '/usr/lib/libsqora.so.11.1’” brings 
 up lots of useful hits.

 regards

 Hugh


 On 12 Mar 2015, at 18:46, Mohammed Alhaj Ali m.al...@itc.sa wrote:

 Hi
 Need help; I'm getting this error log when try to connect to remote DB:

 ERR: Could not connect to SQL database with DBI-connect
 dbi:ODBC:DSLDB, zoouser, zoopass2009: [unixODBC][Driver Manager]Can't
 open lib '/usr/lib/libsqora.so.11.1' : file not found (SQL-01000

 However odbc connection seems to be fine, please check below:


 [root@radiator03 ~]# isql -v DSLDB
 +---+
 | Connected!|
 |   |
 | sql-statement |
 | help [tablename]  |
 | quit  |
 |   |
 +---+
 SQL


 Lookup forward to your help..

 Thank you!
 Regards.




 ___
 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



***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Extracting certificates info for EAP PEAP,TTLS,TLS

[Hartmaier Alexander]

What we've seen is that if a Windows client does EAP authentication,
regardless which one, and it fails it doesn't try to do a DHCP request
even if you reply a radius success and vlan attributes to the switch.

On 2015-02-24 12:12, Christian Kratzer wrote:
 Hi Sami,

 We made progress with our setup thanks to your previous tips.

 We now have following setup simplyfied a bit:

   Handler TunnelledByPEAP=1
   Identifier TunnelledByPEAP=1
   AuthByPolicy ContinueWhileAccept
   AuthBy SQLauthenticate
   AuthBy INTERNALextractFunnyStuffFromRequest
   AuthBy SQLauthorize
   /Handler

   Handler
   Identifier Outer
   AuthBy FILE
   /Handler

 the issue we are currently chasing is that the customer also wants
 failed authentications to proceed into SQLauthorize so he can possible
 put people into a walled garden with specific reply attributes.

 The issue seems to be that when MS-CHAP2 fails in TunneledByPeap it
 seems to kill the EAP session and authentication terminates.

 Subsequent packets are not forwarded to the tunneled handler by the
 outer handler.

 Do you have a suggestion how to accomplish authorization after failed
 chap authentication.

 Terveisin
 Christian




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] AuthBy FILE - Dont check password

[Hartmaier Alexander]

You don't even need that if the file doesn't contain a password check item.

On 2015-01-21 12:02, Peter Havekes wrote:

5.21.58
NoCheckPassword

This optional parameter causes AuthBy not to check the password. This
means that any
password entered by the user will be accepted.
This parameter is useful in conjunction with other authentication
methods where the
password check is done elsewhere.




On 20-01-15 14:17, Jim Tyrrell wrote:


Is it possible to have the AuthBy FILE check a file for the username but
not check the password?

I ideally want the AuthBy to just check for a username in a file of only
usernames, and if it matches generate the Reply, if it fails to match
the username then it will fall back to a 2nd AuthBy (via AuthByPolicy
ContinueWhileReject) that will respond with a different reply.

The idea being that if a user is in a username list the session will be
tunneled to a certain endpoint, and if not the user will be tunneled to
different IP.

Thanks.

Jim.

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







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



***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] AuthBy FILE - Dont check password

[Hartmaier Alexander]

Sure, just use a file with only usernames and no check items. Those are
on the same line as the username, look in the manual for the file format.

Cheers, Alex

On 2015-01-20 14:17, Jim Tyrrell wrote:
 Is it possible to have the AuthBy FILE check a file for the username but
 not check the password?

 I ideally want the AuthBy to just check for a username in a file of only
 usernames, and if it matches generate the Reply, if it fails to match
 the username then it will fall back to a 2nd AuthBy (via AuthByPolicy
 ContinueWhileReject) that will respond with a different reply.

 The idea being that if a user is in a username list the session will be
 tunneled to a certain endpoint, and if not the user will be tunneled to
 different IP.

 Thanks.

 Jim.

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



***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Authorization Cisco ASA

[Hartmaier Alexander]

You need to specify the cmd-arg multiple times, one for each space
separated argument:

authorizedgroup readonly group deny service=shell cmd=changeto 
cmd-arg=context cmd-arg=system
authorizedgroup readonly group permit service=shell cmd=changeto 
cmd-arg=context cmd-arg=other context name
authorizedgroup readonly group deny .*

BR Alex

On 2015-01-05 15:25, Heikki Vatiainen wrote:
 On 5.1.2015 15.34, Steve Normoyle wrote:

 I have a Cisco ASA with multiple context.  I am trying to deny the use
 of the command changeto context system, but allow authorized group to
 be able to change to any of the other context.  When user types in the
 command they get denied.
 Hello Steve,

 does it work if you reorder the first two lines? That is, deny the more
 specific first and allow the less specific then.

 If this does not help, please reply with more debug logs that shows the
 authorization request from ASA with the processing Radiator does.

 I have entered
 authorizedgroup readonly group permit service=shell cmd=changeto
 cmd-arg=context other context name
 authorizedgroup readonly group deny service=shell cmd=changeto
 cmd-arg=context system
 authorizedgroup readonly group deny .*
 Just to make sure: the configuration parameter is AuthorizeGroup (no d
 and with capital A and G). There should especially be no d.

 Thanks,
 Heikki




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] log the matched AuthBy identifier

[Hartmaier Alexander]

On 2014-10-31 20:26, Heikki Vatiainen wrote:
 On 10/24/2014 04:32 PM, Hartmaier Alexander wrote:

 In other words, this would allow you to log %{AuthBy:Identifier} in the
 AuthLog and see which was the last AuthBy that was evaluated.

 Is this what you are thinking of?
 Yes, that would be great, thanks!
 This is now in patches. You can now, for example, log the Identifier of
 the last AuthBy as shown above.

 Thanks,
 Heikki

works like a charm, thanks!


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] log the matched AuthBy identifier

[Hartmaier Alexander]

On 2014-10-24 13:20, Heikki Vatiainen wrote:
 On 23.10.2014 15.31, Hartmaier Alexander wrote:

 I'm trying to log the name of the AuthBy that accepted a request for a
 Handler that has multiple AuthBys.

 I've tried %{Auth-Type}, %{Request:Auth-Type} ad %{Reply:Auth-Type}
 because that's included in the dictionary and mentioned in the reference
 manual for the AuthBy identifier but none of the three worked.
 We could add %{AuthBy:name} special that behaves like %{Handler:name}.
 See section 5.2 Special characters in the reference manual.

 This would give you access to Identifier and other parameters for the
 currently evaluated AuthBy within the AuthBy and the last AuthBy
 evaluated by the Handler. Last would also mean the last AuthBy when the
 AuthByPolicy has determined no more AuthBys should be evaluated.

 In other words, this would allow you to log %{AuthBy:Identifier} in the
 AuthLog and see which was the last AuthBy that was evaluated.

 Is this what you are thinking of?
Yes, that would be great, thanks!

 Thanks,
 Heikki




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] log the matched AuthBy identifier

[Hartmaier Alexander]

Hi guys,
I'm trying to log the name of the AuthBy that accepted a request for a
Handler that has multiple AuthBys.

I've tried %{Auth-Type}, %{Request:Auth-Type} ad %{Reply:Auth-Type}
because that's included in the dictionary and mentioned in the reference
manual for the AuthBy identifier but none of the three worked.

Best regards, Alex


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Certificate updates in Radiator 4.13 patches

[Hartmaier Alexander]

***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
---BeginMessage---
You guys rock!
Your fast actions to user feature requests and general IT trends are
amazing!

Cheers, Alex

On 2014-09-26 10:50, Sami Keski-Kasari wrote:
 Hello all,

 we have now added RSA2048/SHA256 and ECDSA(curve secp256r1)/SHA256 test
 certificates to Radiator 4.13 patches.

 RSA2048/SHA256 certificates requires OpenSSL that includes SHA2 in
 SSL_library_init() or [1]. Please note that certificates are now longer
 which means when using them, for example, with PEAP there will be more
 EAP fragments. Some access points might have problems with them, so if
 you have not yet adjusted EAPTLS_MaxFragmentSize you may need to do so.

 ECDSA(curve secp256r1)/SHA256 certificates require OpenSSL 1.0.0 or
 newer. For ephemeral EC keying Radiator patch dated 2014-09-25 and
 Net-SSLeay 1.58 or newer is required. This may be interesting for long
 lived sessions, such as RadSec links.

 We have tested that Radiator supports ECDSA certificates in all SSL/TLS
 related operations including RadSec, Diameter, PEAP, EAP-TTLS, EAP-TLS, etc.

 Client support for ECDSA certificates seems to be widely available.
 Mobile platforms such as Android version starting 4.1.2, iOS7/8 and WP8
 support ECDSA certificates according to our tests. Windows 7 and modern
 Linux based distributions seem to be working also.

 If you are encountering fragmentation problems with RSA2048/SHA256
 certificates, ECDSA certificates might be a worth trying as they are
 significantly shorter.

 Configuration examples for EAPs, RadSec, Diameter, etc. will be updated
 today.

 [1] SHA-256 support can be made to work with Net-SSLeay 1.46 which
 supports OpenSSL_add_all_algorithms() and a one line addition to
 Radiator to call this function.

 Best Regards,
  Sami




0x4533A0A1.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
---End Message---
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Wireless client verification of Radiator's SSL cert EAP/PEAP

[Hartmaier Alexander]

On 2014-06-19 00:48, Michael Rodrigues wrote:
 Hi,

 I've been searching around the list and the Internet trying to figure
 out how a wireless client can verify the hostname of the SSL cert
 provided by Radiator through the NAS as an SMTP or HTTP client would,
 but I can't seem to find anything insightful. I'm not concerned with how
 the client uses the SSL chain and its included CAs to verify the cert
 cryptographically.

 For one, the client doesn't have Internet to make a reverse lookup until
 they accept the cert.

 Second, even if they were allowed DNS before authentication, someone
 controlling the network could easily catch and spoof the reverse lookup
 reply to make their cert look legitimate (assuming it was
 cryptographically legitimate).

 I'm doing some development/testing and I notice that iOS and Windows 8
 seem to see my certificate as valid but not verified. I setup a PTR
 record to match my host and cert name but it didn't seem to make any
 difference. I monitored tcpdump while authenticating from OS X and I see
 no PTR requests

   I realize each client can have a different implementation. Is it even
 possible to legitimately verify a certificate hostname for clients using
 PEAP and EAP? I'd like to be as secure as possible without resorting to
 client-side certificates.
Security is achieved by configuring a CA cert which you trust, from
which the radius server cert is signed.
In some clients (Windows = Vista is one of them) you can additionally
configure the subject of the certificate to trust.
Lifetime is checked as well, revocation isn't for the clients I know.

 Thanks,
 Michael




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Version 4.13 released

[Hartmaier Alexander]

On 2014-05-05 13:53, Heikki Vatiainen wrote:
 On 05/02/2014 03:24 PM, Hartmaier Alexander wrote:

 I've configured the outer PEAP Handler with EAPTLS_MaxFragmentSize 1350
 and removed the value 1250 (1300 which we use for wired dot1x seems to
 be too large) from the inner TLS handler which makes it fail the same
 way as when configuring 1300.
 Is the other value too large or how is the inner size calculated?
 The inner size simply uses the outer fragment size minus 40 bytes. It
 appears this number is not large enough for all cases then.

 The correct number in your case is something between 1250 and 1300 when
 you have outer fragment size 1350? That is, when you have 1350 as outer
 fragment size, 1250 works but 1300 does not.
So what you're saying is that 1350 for the outer results in an inner
calcuated one of 1310 bytes which is too large?

Which fragment size should be configured, the outer or the inner one?
If the inner is calculated from the outer I shouldn't configure the
inner one but simply reduce the outer one until it works?

The value is the number of bytes the EAP messages are split into and
transmitted via the EAP-Message radius attribute, correct?
So the number is depended on how much bytes all other radius attributes
consume from the MTU which should be 1500 for both wired and wireless in
our case?



 Thanks,
 Heikki

BR Alex


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Version 4.13 released

[Hartmaier Alexander]

On 2014-05-05 15:02, Heikki Vatiainen wrote:
 On 05/05/2014 03:01 PM, Hartmaier Alexander wrote:

 The correct number in your case is something between 1250 and 1300 when
 you have outer fragment size 1350? That is, when you have 1350 as outer
 fragment size, 1250 works but 1300 does not.
 So what you're saying is that 1350 for the outer results in an inner
 calcuated one of 1310 bytes which is too large?
 Yes, the inner EAP-TLS creates fragments of size 1310 and based on your
 message, I understand when these are given to outer PEAP for TLS
 tunneling and transport, the result is too large: it does not fit in 1350.
Can you add a critical logging for that case so the problem can quickly
be found? With a calculated suggested value maybe?


 Which fragment size should be configured, the outer or the inner one?
 If the inner is calculated from the outer I shouldn't configure the
 inner one but simply reduce the outer one until it works?
 It should have worked so that the inner fragmentation matches the outer.
 However, since it does not, you should configure the outer handler
 MaxFragmentSize to as large value as possible, for example 1350 and then
 configure the MaxFragmentSize for the inner AuthBy to as large value as
 possible. It seems 1250 seems to work for you.

 The value is the number of bytes the EAP messages are split into and
 transmitted via the EAP-Message radius attribute, correct?
 Yes, with the addition, that if you have for example an EAP message that
 is 1300 bytes long, it needs to be broken into EAP-Message attributes
 which have payload size of 253 bytes.
Where does the 253 come from?


 So the number is depended on how much bytes all other radius attributes
 consume from the MTU which should be 1500 for both wired and wireless in
 our case?
 Yes. Also the inner AuthBy's MaxFragmentSize must track the outer
 fragment size so that the chunks that inner AuthBy produces do not grow
 too large after TLS processing. This is not a problem with EAP-MSCHAP-V2
 but when EAP-TLS is the inner protocol, then the inner AuthBy requires
 MaxFragmentSize.
So the new feature in 4.13 only helps for PEAP-MSCHAPv2, not for PEAP-TLS?


 Thanks,
 Heikki




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Version 4.13 released

[Hartmaier Alexander]

On 2014-05-05 15:39, Heikki Vatiainen wrote:
 On 05/05/2014 04:18 PM, Hartmaier Alexander wrote:

 Yes, the inner EAP-TLS creates fragments of size 1310 and based on your
 message, I understand when these are given to outer PEAP for TLS
 tunneling and transport, the result is too large: it does not fit in 1350.
 Can you add a critical logging for that case so the problem can quickly
 be found? With a calculated suggested value maybe?
 Good idea. I'll ask if it's possible to detect if the inner request fits in.
Thanks!


 Yes, with the addition, that if you have for example an EAP message that
 is 1300 bytes long, it needs to be broken into EAP-Message attributes
 which have payload size of 253 bytes.
 Where does the 253 come from?
 It's just the RADIUS attribute format: one byte for type, one for length
 and 253 for the payload size since the length field is only one octet long.
So one RADIUS attribute can't get longer than 253 bytes so the EAP
message is split into multiple EAP-Message attributes across multiple
RADIUS request packets as well as multiple times in a single packet?


 Yes. Also the inner AuthBy's MaxFragmentSize must track the outer
 fragment size so that the chunks that inner AuthBy produces do not grow
 too large after TLS processing. This is not a problem with EAP-MSCHAP-V2
 but when EAP-TLS is the inner protocol, then the inner AuthBy requires
 MaxFragmentSize.
 So the new feature in 4.13 only helps for PEAP-MSCHAPv2, not for PEAP-TLS?
 PEAP/EAP-MSCHAP-V2 should not run into fragmentation issue the
 EAP-MSCHAP-V2 message are short. It was meant for PEAP/EAP-TLS since
 EAP-TLS can create long requests.

 Any configuration that worked before 4.13 should work with 4.13 too. The
 idea was to make sure any new configurations would not need to worry
 about fragmentation issues when EAP-TLS was the tunnelled protocol.
Yes, the manual configured values continued to work, our wireless
PEAP-TLS config is a new one, the old used 1024/800.
I just hoped that I could simplify the config and it still works.
Should I try removing MaxFragmentSize from both the PEAP and the TLS
handler?

 Thanks,
 Heikki




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] EAP logging improvements

[Hartmaier Alexander]

Hi,
please change the log message 'None of the desired EAP types (@desired)
are available' in EAP.pm line 213 (version 4.13) to log the EAP type
name instead or in addition to its number, thanks!

BR Alex


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Version 4.13 released

[Hartmaier Alexander]

Hi,
the following new feature seems to not work as I'd expect it:
PEAP and EAP-TTLS now make maximum fragment size available for inner
authentication protocols. EAP-TLS was improved to use this information.
This allows PEAP/EAP-TLS and EAP-TTLS/EAP-TLS to work better with
environments with variable Framed-MTU sizes.

I've configured the outer PEAP Handler with EAPTLS_MaxFragmentSize 1350
and removed the value 1250 (1300 which we use for wired dot1x seems to
be too large) from the inner TLS handler which makes it fail the same
way as when configuring 1300.
Is the other value too large or how is the inner size calculated?

Thanks, Alex

On 2014-04-16 14:45, Heikki Vatiainen wrote:
 We are pleased to announce the release of Radiator version 4.13

 This version contains one new module for authenticating against YubiKey
 validation server and YubiHSM, some significant new features and bug fixes.

 As usual, the new version is available to current licensees from:
 https://www.open.com.au/radiator/downloads/

 and to current evaluators from:
 https://www.open.com.au/radiator/demo-downloads/

 Licensees with expired access contracts can renew at:
 https://www.open.com.au/renewal.html

 An extract from the history file
 https://www.open.com.au/radiator/history.html is below:

 -

 Revision 4.13 (2014-04-16) Radius proxying, IPv6, TACACS+, Diameter and
 other enhancements. Bug fixes


 Selected compatibility notes and enhancements

 Unknown attributes can now be proxied instead of being dropped

 Diameter enhancements may require changes to custom Diameter modules

 Major IPv6 enhancements include: Attributes with IPv6 values can now be
 proxied without IPv6 support, Socket6 is no longer an absolute
 prerequisite. 'ipv6:' prefix is now optional and not prepended in
 attribute values

 TACACS+ authentication and authorization can now be decoupled

 Bind variables are now available for AuthLog SQL and Log SQL.

 Status-Server requests without correct Message-Identifier are ignored.
 Status-Server responses are now configurable.

 LDAP attributes can now be fetched with base scope after subtree scoped
 search. Useful for example, tokenGroups AD attributes which are not
 otherwise available

 Newly added check for CVE-2014-0160, the OpenSSL Heartbleed
 vulnerability may log false positives

 New AuthBy for authenticating against YubiKey validation server added

 See Radiator SIM pack revision history for supported SIM pack versions



 Detailed changes

 Added the attributes from RFC 6911 to dictionary (Framed-IPv6-Address,
 DNS-Server-IPv6-Address, Route-IPv6-Information,
 Delegated-IPv6-Prefix-Pool and Stateful-IPv6-Address-Pool). These
 attributes override a number of attributes that were previously
 commandeered by Ascend and Merit. The Ascend ones are still available in
 ascend.dictionary. The Merit attributes were added under the existing
 Merit VSA entry and the non-VSA Merit attributes were removed from the
 main dictionary. The non-VSA Merit attributes will continue to be
 available in a new file goodies/dictionary.merit

 AuthBy RADIUS and all its subclasses e.g., AuthBy SQLRADIUS, LDAPRADIUS,
 MULTICAST and proxy algorithm AuthBys, now support special characters in
 AuthPort and AcctPort. Suggested by David Zych.

 Added in dictionary: Huawei-Loopback-Address, vendor 6139
 (Alcatel-Lucent OmniAccess), vendor 20942 (China Telecom-Guangzhou
 Research and Development Center) and vendor 27262 DANTE Ltd.

 Unknown attributes can now be proxied when the new global configuration
 flag ProxyUnknownAttributes is set to true. Unknown attributes are now
 alwasy available with special names such as Unknown-9048-120, where 9048
 is the vendor id and 120 is the vendor attribute number. Unknown
 attributes are now logged with level WARNING instead of ERR. A warning
 is logged for each attribute once per sender IP address. Attribute names
 starting with Unknown are reserved in dictionary and ignored when the
 dictionary is loaded.

 Added in dictionary: Attributes from RFC 5447, RFC 6519, RFC 6677 and
 RFC 6930.

 Added support for dictionary type ipv4prefix required by RFC 6572. An
 example of ipv4prefix format is '192.168.1.0/24'. Added attributes from
 RFC 6572 in dictionary.

 Change in 4.12 caused ServerDIAMETER to always create new peer instances
 for new connections. This caused mainly WatchdogState DOWN log litter.

 AuthBy DIAMETER and other DiameterClient derived classes, such as
 Diameter Wx based EAP-SIM, EAP-AKA and EAP-AKAPRIME AuthBys, now support
 new option SCTPPeer. This option allows defining multiple SCTP peers for
 the initial SCTP association attempt.

 Added vendor Arista in dictionary. Updated Netscreen values. Contributed
 by Garry Shtern.

 Fixed AuthBy NTLM so it will not leave zombie processes around during
 reconfigure. Reported by Garry Shtern.

 AuthBy RATELIMIT now supports optional parameter MaxRateResult, which
 allows specifying the result when MaxRate 

Re: [RADIATOR] Serious Open SSL bug

[Hartmaier Alexander]

On 2014-04-08 00:20, Johnson, Neil M wrote:

Just received notice from our security folks about this bug which may lead to 
leaking of the private key used to sign SSL certs and encrypt traffic.

More info can be of found here: http://heartbleed.com/

Are you guys aware of this and have plans to update the PERL SSL module for 
RADIATOR ?
The Perl Net::SSLeay module is just a binding for the underlying OpenSSL 
library, if it is patched the Perl apps aren't vulnerable as well.


-Neil

--
Neil Johnson
Network Engineer
The University of Iowa
Phone: 319 384-0938
Fax: 319 335-2951
E-Mail: neil-john...@uiowa.edumailto:neil-john...@uiowa.edu







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

--
Best regards, Alexander Hartmaier

T-Systems Austria GesmbH
TSS Security Services
Network Security  Monitoring Engineer

phone: +43(0)57057-4320
fax: +43(0)57057-954320



***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch

[Hartmaier Alexander]

Hi Heikki,
attached is what I just wrote, feedback welcome!

Feel free to include it in the Radiator dist with an extended copyright,
different name, ...

Best regards, Alex

On 2014-04-04 14:42, Heikki Vatiainen wrote:
 On 04/03/2014 12:28 PM, Hartmaier Alexander wrote:

 I just checked, LogFormat is indeed defined in LogFILE.pm, I thought it
 is shared by different logging classes and defined in a base class.
 You are correct, there's no common class for LogFILE but the common
 class is LogGeneric instead. And since logs can be pushed to for
 example, SQL, LogFormat is only defined in LogFILE.

 I don't care so much where it is defined but how.
 Do you think configuring a Perl sub that returns a serialized string is
 the way to go for structured logging?
 I guess that would be like a in-line Hook? Maybe it could be configured
 as a hook type of parameter with a default value. See for example,
 SqlDb.pm and how ConnectionAttemptFailedHook is initialised with a
 default hook code.

 I was thinking about writing a Log module that uses Log::Any, Log4perl
 or Log::Dispatch so that you can do everything these modules support.
 My only concern is that the logging module affects Radiator and if e.g.
 RabbitMQ is down and logs can't be stored Radiator stops working.
 This might be intended if logging is an absolute requirement, but others
 might prefer availability over logging. Ideally this should be configurable.
 Indeed. As noted below, LogSQL can be configured with so that it won't
 make everything stop unless required so.

 What happens for the LogSQL class if the database goes down?
 It uses the functions defined in SqlDb.pm which for example, AuthBy SQL
 uses. Because of this, LogSQL respects FailureBackoffTime, Timeout and
 other common parameters AuthBy SQL uses.

 Is there some documentation how to write a Log class? I looks like It
 only has to have the ConfigKeywords hash, subclass from
 Radius::LogGeneric and an initialize and log sub.
 I'd say the existing Log* files are the best example.

 Is there anything special I need to do to allow a ConfigKeyword to hold
 a Perl sub?
 Maybe create it as a Hook? That should help not duplicating existing
 functionality.

 Thanks,
 Heikki


 BR Alex


 Thanks,
 Heikki



 ***
 T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
 Handelsgericht Wien, FN 79340b
 ***
 Notice: This e-mail contains information that is confidential and may be 
 privileged.
 If you are not the intended recipient, please notify the sender and then
 delete this e-mail immediately.
 ***





LogStructured.pm
Description: Perl program
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch

[Hartmaier Alexander]

On 2014-04-02 20:57, Heikki Vatiainen wrote:
 On 04/01/2014 02:59 PM, Hartmaier Alexander wrote:

 I think extending LogFormat is the right way to go because one might
 want to log to a file or database in json or yaml as well.
 What I still haven't figured out is a config format.
 Enabling to pass a Perl sub to LogFormat would be the most flexible
 option but not the most user friendly.

 Ideas?
 Wouldn't subclassing Log FILE work. Or maybe subclassing LogGeneric
 directly? I'd think keeping Log FILE as simple and straight forward
 would be a good goal since sometimes (Trace 4) a lot of traffic will
 pass through it.
I just checked, LogFormat is indeed defined in LogFILE.pm, I thought it
is shared by different logging classes and defined in a base class.
I don't care so much where it is defined but how.
Do you think configuring a Perl sub that returns a serialized string is
the way to go for structured logging?
I was thinking about writing a Log module that uses Log::Any, Log4perl
or Log::Dispatch so that you can do everything these modules support.
My only concern is that the logging module affects Radiator and if e.g.
RabbitMQ is down and logs can't be stored Radiator stops working.
This might be intended if logging is an absolute requirement, but others
might prefer availability over logging. Ideally this should be configurable.

What happens for the LogSQL class if the database goes down?

Is there some documentation how to write a Log class? I looks like It
only has to have the ConfigKeywords hash, subclass from
Radius::LogGeneric and an initialize and log sub.

Is there anything special I need to do to allow a ConfigKeyword to hold
a Perl sub?

BR Alex



 Thanks,
 Heikki




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch

[Hartmaier Alexander]

On 2014-03-28 09:02, Hartmaier Alexander wrote:
 On 2014-03-27 20:43, Heikki Vatiainen wrote:
 On 03/27/2014 05:22 PM, Hartmaier Alexander wrote:

 Did you have time to work on this feature?
 We have worked on EAP-SIM, Diameter and other RADIUS functionality, but
 not this. It's still on the ideas to explore list, though.

 I've started tring to get all Radiator logs into Elasticsearch via
 RabbitMQ and found out that Log FILE also closes the pipe in case of
 Filename |/etc/radiator/log_to_rabbitmq.pl which is a performance problem.
 It makes the log files easy to rotate, but I can see why it's not good
 in this case.
 Because the logging script has some quite a 'high' startup time because
 it has to connect to RabbitMQ and also disconnects immediatly afterwards
 causing quite some overhead and RabbitMQ logging.
 The comment in Radius::Util::append says:
 # Current implementation opens, writes and closes
 # Future implementations might hold the file open, and reopen on
 # signal, or perhaps pipe to a daemon

 I need a feature that keeps the spawned (forked?) process open and pipe
 to it.
 I'd also need to escape the log message so my JSON doesn't break in case
 the message contains one or more .

 LogFormat { timestamp:%Y-%m-%d %H:%M:%S, priority:%1,
 message:%2 }
 Hmm, maybe a new class that could be configured to support the above? It
 would need to be able to quote the log messages, maybe a configurable
 method for different kinds of destinations (JSON, etc), hold the fd open
 while supporting FarmSize and possibly something else too. I'd say
 extending Log FILE may not be a good idea but to have a new logging class.

 If you already have something that does what you require on the Log
 ... side, please get back to me directly.
 Yeah, I was thinking about writing a LogMessagePassing or Log4perl class
 but am not sure to which api I have to follow as its internal and as far
 as I know undocumented.
 For now I've created a named pipe which I configured Radiator to log to
 and have a Message::Passing DSL script that runs as daemon using
 Daemon::Control which uses the TailFile input and the AMQP output.
 I wanted to not have to run that extra daemon because it's one more
 thing that can go wrong.
I need a solution that outputs structed log messages serialized as JSON
fast.
My quick solution is:

Log FILE
   # this is a named pipe created using mkfifo
Filename %L/radiator.fifo
LogFormat { timestamp:%Y-%m-%dT%H:%M:%SZ, source_host:%h,
priority:%1, type:radiator,
customer:%{OSC-Customer-Identifier}, message:%2 }
Trace 3
/Log

The problem is that some messages contain linefeeds (openssl library
errors when using EAP-TLS for example) which don't get escaped as per
JSON spec and make the JSON parsing fail.

I think extending LogFormat is the right way to go because one might
want to log to a file or database in json or yaml as well.
What I still haven't figured out is a config format.
Enabling to pass a Perl sub to LogFormat would be the most flexible
option but not the most user friendly.

Ideas?


 Thanks,
 Heikki




 ***
 T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
 Handelsgericht Wien, FN 79340b
 ***
 Notice: This e-mail contains information that is confidential and may be 
 privileged.
 If you are not the intended recipient, please notify the sender and then
 delete this e-mail immediately.
 ***
 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator

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

Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch

[Hartmaier Alexander]

On 2014-03-27 20:43, Heikki Vatiainen wrote:
 On 03/27/2014 05:22 PM, Hartmaier Alexander wrote:

 Did you have time to work on this feature?
 We have worked on EAP-SIM, Diameter and other RADIUS functionality, but
 not this. It's still on the ideas to explore list, though.

 I've started tring to get all Radiator logs into Elasticsearch via
 RabbitMQ and found out that Log FILE also closes the pipe in case of
 Filename |/etc/radiator/log_to_rabbitmq.pl which is a performance problem.
 It makes the log files easy to rotate, but I can see why it's not good
 in this case.
Because the logging script has some quite a 'high' startup time because
it has to connect to RabbitMQ and also disconnects immediatly afterwards
causing quite some overhead and RabbitMQ logging.

 The comment in Radius::Util::append says:
 # Current implementation opens, writes and closes
 # Future implementations might hold the file open, and reopen on
 # signal, or perhaps pipe to a daemon

 I need a feature that keeps the spawned (forked?) process open and pipe
 to it.
 I'd also need to escape the log message so my JSON doesn't break in case
 the message contains one or more .

 LogFormat { timestamp:%Y-%m-%d %H:%M:%S, priority:%1,
 message:%2 }
 Hmm, maybe a new class that could be configured to support the above? It
 would need to be able to quote the log messages, maybe a configurable
 method for different kinds of destinations (JSON, etc), hold the fd open
 while supporting FarmSize and possibly something else too. I'd say
 extending Log FILE may not be a good idea but to have a new logging class.

 If you already have something that does what you require on the Log
 ... side, please get back to me directly.
Yeah, I was thinking about writing a LogMessagePassing or Log4perl class
but am not sure to which api I have to follow as its internal and as far
as I know undocumented.
For now I've created a named pipe which I configured Radiator to log to
and have a Message::Passing DSL script that runs as daemon using
Daemon::Control which uses the TailFile input and the AMQP output.
I wanted to not have to run that extra daemon because it's one more
thing that can go wrong.


 Thanks,
 Heikki





***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch

[Hartmaier Alexander]

On 2013-09-20 12:15, Hartmaier Alexander wrote:
 On 2013-09-20 11:44, Heikki Vatiainen wrote:
 On 09/20/2013 11:35 AM, Alexander Hartmaier wrote:

 @Radiator guys: are you interessted in supporting Message::Passing,
 Log::Log4perl or Log::Any?
 They support a lot of outputs which would be a great feature addition!
 Sounds interesting. So this would be for Accounting, at least first, or
 do you see need for other passing other information through these too?
 I'd prefer having this support for all types of logs.
 Maybe extending Log to handle authentication, accounting and general
 radiator logs would make sense.

 AuthLog would become
 Log MessagePassing (or all other currently available like Log FILE)
 Auth 1
 Acct 0
 Other 0
 ...
 /Log

 If you don't want to change the config DSL so much the Log and AuthLog
 stanzas would both need to support each output.
 Haven't looked at the code yet but I guess there is much too share
 between them and AuthLog could internally become just an alias for
 LogAuth 1, Acct 0, Other 0.

 Accounting logging is currently handled entirely different as there is
 no AcctLog.
Did you have time to work on this feature?
I've started tring to get all Radiator logs into Elasticsearch via
RabbitMQ and found out that Log FILE also closes the pipe in case of
Filename |/etc/radiator/log_to_rabbitmq.pl which is a performance problem.

The comment in Radius::Util::append says:
# Current implementation opens, writes and closes
# Future implementations might hold the file open, and reopen on
# signal, or perhaps pipe to a daemon

I need a feature that keeps the spawned (forked?) process open and pipe
to it.
I'd also need to escape the log message so my JSON doesn't break in case
the message contains one or more .

LogFormat { timestamp:%Y-%m-%d %H:%M:%S, priority:%1,
message:%2 }

Thanks, Alex

 As always, any additional ideas and comments from the list members would
 be appreciated too.

 Yes, please, speak up everybody!


 ***
 T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
 Handelsgericht Wien, FN 79340b
 ***
 Notice: This e-mail contains information that is confidential and may be 
 privileged.
 If you are not the intended recipient, please notify the sender and then
 delete this e-mail immediately.
 ***
 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator

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

Re: [RADIATOR] Radiator using WPA2-Enterprise and dynamic VLAN Assignment (Part 1)

[Hartmaier Alexander]

On 2014-03-26 18:40, Roberto Pantoja wrote:
I have a problem trying to assign dynamic VLANs to users on a  WPA2-Enterprise 
configuration. Users have successful authentication and if I don't send the 
Radius Attribute Tunnel-Private-Group-ID The Wireless Controller connects me 
to the default VLan for the SSID, but when I send Tunnel-Private-Group-ID, 
the Wireless Controller simply drops out my connection. The Wireless controller 
documentation says the required attributes in the Access-Accept Reply are 
Tunnel-Type=VLAN, Tunnel-Medium-Type=802, Tunnel-Private-Group-ID=Name of 
VLAN.  Everything works fine using Ignition Server (Avaya's Radius Server). 
But on product's documentation says WC8180 comply with RFC Standards and 
mentions to be compatible and validated with freeradius and Microsoft IAS, so 
I think my case is a configuration issue.

Regards.

Radiator Version: 4.12.1
Wireless Controller: AVAYA WC8180
Wireless Access Points: AVAYA AP8120

Config file:
*** Config File ***
# radius.cfg

Foreground
LogStdout
LogDir  /var/log/radius
LogFile %L/logfile.%Y.%m.%d
DbDir   /etc/radiator
# User a lower trace level in production systems:
Trace   4
AuthPort 1812
AcctPort 1813

Client 10.0.30.254
Secret verysecret
PacketTrace
Identifier Avaya WC8180
/Client

Handler TunnelledByPEAP=1
AuthBy FILE
Filename %D/users
EAPType MSCHAP-V2
/AuthBy
/Handler

Handler
AuthBy FILE
Filename %D/users
EAPType PEAP
EAPTLS_CAFile %D/certificates/cacert.pem
#   EAPTLS_CAPath
EAPTLS_CertificateFile %D/certificates/radiator-cert.pem
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile %D/certificates/radiator-key.pem
EAPTLS_PrivateKeyPassword verysecret
#   EAPTLS_RandomFile %D/certificates/random
EAPTLS_MaxFragmentSize 1024
#   EAPTLS_DHFile %D/certificates/cert/dh
#EAPTLS_CRLCheck
#EAPTLS_CRLFile %D/certificates/crl.pem
#EAPTLS_CRLFile %D/certificates/revocations.pem
AutoMPPEKeys
#EAPTLS_SessionResumption 0
#EAPTLS_SessionResumptionLimit 10
EAPAnonymous anonymous@localhost
EAPTLS_PEAPVersion 0
EAPTTLS_NoAckRequired
/AuthBy
/Handler
*** EOF Config File ***


Users file:
mikem user without VLAN default VLAN - Quarantine - no IP address
mikem1 user with VLAN Empleados - IP address range 10.0.21.0/24
mikem2 user with VLAN ATI - IP address range 10.0.19.0/24
*** Users file ***
# users
# This is an example of how to set up simple user for
# AuthBy FILE.
# The example user mikem has a password of fred, and will
# receive reply attributes suitable for most NASs.
# You can do many more interesting things. See the Radiator reference
# manual for more details
#
# You can test this user with the command
#  perl radpwtst

mikem   User-Password=fred
Service-Type = Framed-User,
Tunnel-Medium-Type = 802,
Tunnel-Type = VLAN

mikem1  User-Password=fred
Service-Type = Framed-User,
Tunnel-Private-Group-ID = Empleados,
Tunnel-Medium-Type = 802,
Tunnel-Type = VLAN

mikem2  User-Password=fred
Service-Type = Framed-User,
Tunnel-Private-Group-ID = ATI,
Tunnel-Medium-Type = 802,
Tunnel-Type = VLAN

*** EOF users file ***

We're doing that with Cisco WLCs without problems but in our case by sending 
the VLAN ID, not its name like for wired dot1x where Cisco IOS switches want 
the VLAN name:

AddToReply Tunnel-Type=VLAN,\
   Tunnel-Medium-Type=802, \
   Tunnel-Private-Group-ID=123


--
---
Roberto Carlos Pantoja Valdizón
Analista de Sistemas
ATI/GDEI/LaGeo



This message has been scanned for malware by Websense. 
www.websense.comhttp://www.websense.com/



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



***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Problems with radiator to radsecproxy TLS connections

[Hartmaier Alexander]

Hi Elmar,

On 2014-03-24 17:10, Elmar Dreher wrote:
 Hello all,

 i am systemadministrator for eduroam at the university of Konstanz.
 We are using radiator and radsecproxy:
 1. Radiator is hosted in an Application Zone
 2. Radsecproxy is hosted in a DMZ and connected to the DFN for eduroam 
 purposes
 3. OS on both environments is Ubuntu 12.04

 The setup is the following:
 1. All connection (beetween radiator and radsecproxy) are implemented by 
 using TLS
 2. On radiator the RADSEC implementaion is used to realize TLS connetion from 
 and to radsecproxy
 3. Radiator an radsecproxy are redundant (2 radiators and 2 radsecproxies) 
 and are connected redundant


 Now the problem:
 Soemtimes it happens that the connection between radsecproxy - radiator is 
 broken (experience has shown after 5 to 6 weeks):
 At case of an eduroam Login attempt radsecproxy or radiator is logging that 
 the remote peer isn't available.
 Looking an the network connection with netstat -tapen everythink looks ok.

 Does everbody have the same experience with this architecture or does have an 
 idea or hint what could be the problem or how to solve the problem (we 
 already have a weekly reboot of all radsecproxy and radiator services and 
 everything works fine).
Maybe a stateful firewall is dropping the tcp connection from its
connection table because of inactivity longer than its tcp idle timeout?
You should enable tcp keepalives in the linux kernel and lower its
values so it kicks in before the firewall removes the idle tcp
connection from its connection tracking table.

See http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html

  Many greetings from Konstanz, Elmar Dreher
 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator



***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Cisco NX-OS TACACS+ problems

[Hartmaier Alexander]

On 2014-02-07 08:35, Hartmaier Alexander wrote:
 On 2014-02-06 23:11, Heikki Vatiainen wrote:
 On 10/11/2013 11:38 AM, Alexander Hartmaier wrote:

 our switching guys reported that their Cisco Nexus switches running
 NX-OS log that their can't reach the tacacs servers. This is what the
 troubleshooting brought up:

 2013 Oct 11 08:47:37.061 sgv20s %TACACS-3-TACACS_ERROR_MESSAGE: All
 servers failed to respond
 Returning to the subject with new information. This problem was seen by
 others too and this time a fix seems to be found.

 The bug appears to be CSCtz32293 and is corrected in 5.2(1)N1(5). The
 upgrade was done to 5.2(1)N1(6) which shows no problems.

 A similar looking problem is also described here:
 http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080c17808.shtml

 I'm not sure if this relates to Steve's problem but looks exactly what
 Alexander was seeing.
 Thanks for keeping track of this problem!!!
 I had no time to further investigate it with our switching guys but
 informed them about the update.
Sadly they are already running version 5.2(1)N1(6) and the error
messages still occur.

 Thanks,
 Heikki



 ***
 T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
 Handelsgericht Wien, FN 79340b
 ***
 Notice: This e-mail contains information that is confidential and may be 
 privileged.
 If you are not the intended recipient, please notify the sender and then
 delete this e-mail immediately.
 ***
 ___
 radiator mailing list
 radiator@open.com.au
 http://www.open.com.au/mailman/listinfo/radiator

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

Re: [RADIATOR] Cisco NX-OS TACACS+ problems

[Hartmaier Alexander]

On 2014-02-06 23:11, Heikki Vatiainen wrote:
 On 10/11/2013 11:38 AM, Alexander Hartmaier wrote:

 our switching guys reported that their Cisco Nexus switches running
 NX-OS log that their can't reach the tacacs servers. This is what the
 troubleshooting brought up:

 2013 Oct 11 08:47:37.061 sgv20s %TACACS-3-TACACS_ERROR_MESSAGE: All
 servers failed to respond
 Returning to the subject with new information. This problem was seen by
 others too and this time a fix seems to be found.

 The bug appears to be CSCtz32293 and is corrected in 5.2(1)N1(5). The
 upgrade was done to 5.2(1)N1(6) which shows no problems.

 A similar looking problem is also described here:
 http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080c17808.shtml

 I'm not sure if this relates to Steve's problem but looks exactly what
 Alexander was seeing.
Thanks for keeping track of this problem!!!
I had no time to further investigate it with our switching guys but
informed them about the update.


 Thanks,
 Heikki




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Huawei VSAs

[Hartmaier Alexander]

On 2014-02-04 14:57, Heikki Vatiainen wrote:
 On 02/03/2014 02:27 PM, Hartmaier Alexander wrote:

 I've added some more Huawei VSAs to the dictionary, please include them
 in the standard dictionary file, thanks!
 Done. Thanks.

 VENDORATTR2011Huawei-Requested-APN168string
 VENDORATTR2011Huawei-GGSN-Vendor232string
 VENDORATTR2011Huawei-GGSN-Vendor233string
 Do 232 and 233 have the same name?
Sorry, my bad, it's Version, not Vendor:

VENDORATTR2011Huawei-GGSN-Version233string



 Heikki




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] multiple EAP-TLS AuthBys

[Hartmaier Alexander]

That worked like a charm!
Thanks Heikki!

Is this because of historical reasons?

On 2014-02-04 14:54, Heikki Vatiainen wrote:
 On 02/03/2014 06:46 PM, Hartmaier Alexander wrote:

 You might be able to use EAPTLS_CertificateVerifyHook to check which CA
 matched. However, I have not checked in detail if this is possible. I
 would first see if the requests have any information that could help
 with Handler selection.
 I already wrote a handler but the weird things are:
 - $matchedcn is undefined. Is this because I'm doing AuthBy FILE with
 AcceptIfMissing or because of EAPTLS_NoCheckId?
 I think it's because of EAPTLS_NoCheckId. There might be still a way to
 use EAPTLS_CertificateCerifyHook, even with this option enabled.

 - I don't have access to the reply packed in the hook which makes
 assigning a different value to the Tunnel-Private-Group-ID attribute
 more complicated than necessary.
 You could use $p-{EAPContext} to store the information. It would then
 be available when the authentication finishes. The reply when the hook
 runs would be for Access-Challenge, not for the final Access-Accept.

 You could try this. In the EAPTLS_CertificateVerifyHook store the
 certificate issuer in the context and return for example, 'DEFAULT'.
I return the cert issuer's name as the return value isn't processed any
further.
I tried to put the radius reply attribute into the users file and create
one user per company but that didn't work out either.

 $_[5]-{EAPContext}-{cert_issuer} =
 Net::SSLeay::X509_NAME_oneline(Net::SSLeay::X509_get_issuer_name($_[2]));
I saw that $_[5]-{EAPContext} is a Radius::Context object. Is there an
API for hook added values so I don't accidentally overwrite a Radiator
internal attribute?


 In PostAuthHook map the issuer name to VLAN id when the result is
 ACCEPT. Then use $rp-add_attr() to add Tunnel-Private-Group-ID with the
 value off VLAN id.
The one odd thing is that some hooks like for example the PostAuthHook
get their params as references which doesn't allow
my ($p, $rp, $result) = @_;
but you have to derefernce them instead like
my $p = ${$p};

 This might work especially if there are not too many issuers and issuer
 is enough to establish which CA is used. Otherwise more complete
 certificate chain walk would be required.
I have only the direct issuing certs in the cert directory, so I don't
have to check the cert chain.

 Thanks,
 Heikki




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] IPv6 enhancements in current patches: IPV6_V6ONLY and IPv6 CIDR clients

[Hartmaier Alexander]

On 2013-11-30 22:40, Heikki Vatiainen wrote:
 On 11/29/2013 04:04 PM, Hartmaier Alexander wrote:

 I've just read the IPv6 section in the 4.12.1 reference manual after
 installing 4.12.1 on a new RHEL6 box which has IPv6 support disabled via
 'alias ipv6 off' and 'options ipv6 disable=1' in /etc/modprobe.d/local.conf.

 On startup Radiator logs: 'INFO: This system is IPv6 capable. IPv6
 capability provided by: core' although the Socket6 module isn't
 installed because its tests fail because IPv6 support is disabled in the
 Linux kernel.
 That's interesting. Does Socket6 compilation really check if IPv6 is
 disabled in the system?

 The Radiator log message is about the IPv6 capability of the Perl that
 was used to invoke radiusd. Now that you mentioned, it might be better
 to say that the system has IPv6 capable Perl and the Perl IPv6
 capability required by Radiator is provided by Perl core (or Socket6 or
 none).

 In your case, even if you can not use BindAddress ::, radiusd can still
 process attributes with IPv6 addresses and prefixes without problems
 since the Perl core libraries have support for e.g., getaddrinfo().

 But the manual says 'Note: Currently IPv6 support requires Socket6.pm
 Perl module.'. Which one is correct, the manual or the log message?
 The manual is correct for Radiator 4.12.1 as it was released. Binding to
 IPv6 addresses, address packing and other functions and decoding and
 encoding of IPv6 addresses and prefix in attributes requires Socket6.pm
 with 4.12.1.
In a recent p5p mailing list discussion Paul Evans confirmed that
Socket6 isn't needed these days as the core Socket has all functions
required:
https://rt.perl.org/Public/Bug/Display.html?id=75740#txn-1278801

Please rework Radiator's code to use a new-enough Socket.pm instead of
the deprecated Socket6.pm, thanks!
If everything goes well IO::Socket::IP will be in core Perl 5 Version
20, which will be released in March, as a replacement for
IO::Socket::INET to provide IPv4 and IPv6 support.
So if you're using ::INET today please replace it with ::IP and test it.
You can also use Acme::Override::INET to override all ::INET with ::IP
calls.


 The patches in 4.12.1 check Perl's IPv6 capability and try to prefer the
 built in core modules. If the core does not support all the required
 functionality, then presence of Socket6.pm is checked. If there is no
 Socket6.pm either then IPv6 addresses and prefixes can not be encoded
 and decoded in human readable format and are processed as binary data
 which works for proxying.
That already sounds like it's using Socket instead of Socket6. I
recommend to remove Socket6 at all and require a newer Socket.pm instead.

 The Perl version is 5.16.3 compiled on the box using perlbrew.
 Perl 5.16.3 is recent enough, I think 5.14.0 has everything required, so
 radiusd finds the core modules in 5.16.3 can be used. Also, since you
 get the log message about IPv6 capability, it means you have Radiator
 4.12.1 + patches.

 The very first sentence doesn't mention TACACS+, does it support IPv6
 too or not?
 ServerTACACSPLUS should work with IPv6. Looks like
 goodies/tacacsplustest does not support IPv6 for testing yet, but the
 server side should work.
Good to know, thanks!


 Please add this info.
 The documentation regarding Socket6.pm not required for recent enough
 Perls will be in the next release's documentation. We can also mention
 TACACS+ too.

 Thanks,
 Heikki

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



***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Huawei VSAs

[Hartmaier Alexander]

I've added some more Huawei VSAs to the dictionary, please include them
in the standard dictionary file, thanks!

VENDORATTR2011Huawei-Requested-APN168string
VENDORATTR2011Huawei-GGSN-Vendor232string
VENDORATTR2011Huawei-GGSN-Vendor233string


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] multiple EAP-TLS AuthBys

[Hartmaier Alexander]

Hi Heikki,

On 2014-02-03 17:10, Heikki Vatiainen wrote:
 On 01/31/2014 02:23 PM, Hartmaier Alexander wrote:

 I'm trying to get a wired and wireless 802.1x config working where in
 one building shared Cisco IOS switches and Cisco WLAN controllers are
 used for multiple companies, each with its own CA.
 My handler config is below and as you can see the EAPTLS settings share
 the same radius server certificate but only differ in the CA cert used
 to validate the clients cert.
 If the clients have different certs from different CAs, you should be
 able to use EAPTLS_CAPath instead of EAPTLS_CAFile.

 Note that the certificate file names have special requirements. See
  https://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html

 and look for the c_rehash utility.
I'm already using that for one of the AuthBy's because the certs come
from an old and a new CA.

 The level 4 trace showed that the first AuthBy responds with a challenge
 which didn't match the ContinueUntilAccept AuthByPolicy so the second
 AuthBy was triggered which failed as well.

 I've changed the AuthByPolicy to ContinueUntilAcceptOrChallenge but now
 always the first AuthBy is checked until the client gives up authenticating.
 I'd say CAPath is better idea than trying to match client CAs with
 individual AuthBys unless there is a way to differentiate between clients.

 Is there anything in the requests client generate that could help with
 choosing the correct Handler?
Sadly not because the requirement is to have a single SSID for all
companies, the same goes for wired 802.1x where the same switch port
should be put into a specific VLAN per company.

 Another possibility would be a single AuthBy with all CA certs but how
 would I differentiate which one matched to send different
 Tunnel-Private-Group-ID values back?
 You might be able to use EAPTLS_CertificateVerifyHook to check which CA
 matched. However, I have not checked in detail if this is possible. I
 would first see if the requests have any information that could help
 with Handler selection.
I already wrote a handler but the weird things are:
- $matchedcn is undefined. Is this because I'm doing AuthBy FILE with
AcceptIfMissing or because of EAPTLS_NoCheckId?
- I don't have access to the reply packed in the hook which makes
assigning a different value to the Tunnel-Private-Group-ID attribute
more complicated than necessary.


 Thanks,
 Heikki

Cheers, Alex


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] multiple EAP-TLS AuthBys

[Hartmaier Alexander]

Hi guys,
I'm trying to get a wired and wireless 802.1x config working where in
one building shared Cisco IOS switches and Cisco WLAN controllers are
used for multiple companies, each with its own CA.
My handler config is below and as you can see the EAPTLS settings share
the same radius server certificate but only differ in the CA cert used
to validate the clients cert.

The level 4 trace showed that the first AuthBy responds with a challenge
which didn't match the ContinueUntilAccept AuthByPolicy so the second
AuthBy was triggered which failed as well.

I've changed the AuthByPolicy to ContinueUntilAcceptOrChallenge but now
always the first AuthBy is checked until the client gives up authenticating.

I haven't found an example in the goodies that matches our setup.

Another possibility would be a single AuthBy with all CA certs but how
would I differentiate which one matched to send different
Tunnel-Private-Group-ID values back?

Best regards, Alex


Handler Client-Identifier=wlancontroller,
Called-Station-Id=/:dot1xtest$/, EAP-Message=/.+/
# first try
AuthByPolicy ContinueUntilAccept
# second try
AuthByPolicy ContinueUntilAcceptOrChallenge

AuthBy FILE
Identifier wlan-dot1xtest-company1

Filename %D/users.dot1x
AcceptIfMissing

EAPTLS_NoCheckId
EAPType TLS
EAPTLS_MaxFragmentSize 1350

EAPTLS_CAFile %D/certificates/company1/CA.pem
EAPTLS_CertificateFile
%D/certificates/shared/dot1xradius.company.tld.pem
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile
%D/certificates/shared/dot1xradius.company.tld.key
EAPTLS_PrivateKeyPassword foobar
EAPTLS_CRLCheck
EAPTLS_CRLFile %D/certificates/company1/CA.crl.pem

AutoMPPEKeys

AddToReply Tunnel-Type=VLAN
AddToReply Tunnel-Medium-Type=802
AddToReply Tunnel-Private-Group-ID=100
/AuthBy

AuthBy FILE
Identifier wlan-dot1xtest-company2

Filename %D/users.dot1x
AcceptIfMissing

EAPTLS_NoCheckId
EAPType TLS
EAPTLS_MaxFragmentSize 1350

EAPTLS_CAFile %D/certificates/company2/CA.pem
EAPTLS_CertificateFile
%D/certificates/shared/dot1xradius.company.tld.pem
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile
%D/certificates/shared/dot1xradius.company.tld.key
EAPTLS_PrivateKeyPassword foobar
EAPTLS_CRLCheck
EAPTLS_CRLFile %D/certificates/company2/CA.crl.pem


AutoMPPEKeys

AddToReply Tunnel-Type=VLAN
AddToReply Tunnel-Medium-Type=802
AddToReply Tunnel-Private-Group-ID=200
/AuthBy

AuthLog FILE
Filename %L/wlan-dot1xtest.authlog
LogSuccess 1
LogFailure 1

SuccessFormat %Y-%m-%d
%H:%M:%S:%U:%{Called-Station-Id}:%{Calling-Station-Id}:%{Reply:Tunnel-Private-Group-ID}::OK
FailureFormat %Y-%m-%d
%H:%M:%S:%U:%{Called-Station-Id}:%{Calling-Station-Id}:%{Reply:Tunnel-Private-Group-ID}:%1:FAIL
/AuthLog

/Handler


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] suggested hash algorithm for passwords in text files

[Hartmaier Alexander]

On 2014-01-29 14:38, Heikki Vatiainen wrote:
 On 01/13/2014 06:58 PM, Hartmaier Alexander wrote:

 Patching is welcome! If you'd add those formats we would immediately
 switch to using them.
 Hello Alexander,

 support for {SHA256}, {SSHA256} and the 384 and 512 digest lengths is
 now in patches. These new formats are similar to the existing {SHA} and
 {SSHA} formats.

 Support for PBKDF2 derived passwords should also be available soon.
 Because of EAP-PSK, Radiator already has a portable PBKDF2
 implementation so using it for password stretching is fairly straight
 forward.

 The suitable format is still a bit of question. Crypt-PBKDF2, for
 example, seems to support LDAP and crypt style formats:

 {X-PBKDF2}HMACSHA1:AAAD6A:8ODUPA==:1HSdSVVwlWSZhbPGO7GIZ4iUbrk=
 $PBKDF2$HMACSHA1:1000:4q9OTg==$9Pb6bCRgnct/dga+4v4Lyv8x31s=

 We would be interested to hear if there are other formats that should be
 supported.

 Thanks,
 Heikki

Awesome! I'll look into upgrading our Radiator installation and will
report back.


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] suggested hash algorithm for passwords in text files

[Hartmaier Alexander]

On 2014-01-13 17:17, Heikki Vatiainen wrote:
 On 01/10/2014 03:15 PM, Hartmaier Alexander wrote:

 As MD5 isn't recommended these days and we don't want to use some
 vendor/product specific algorithm like the mysql or mssql ones I'm
 looking for something like SHA256 or better.
 Digest::SHA is a required module since version 4.10 but it's sha256 and
 sha512 methods seem to be unused currently.
 That is correct, there is no {...} format for SHA-256 or SHA-512.
 However, crypt(3) formats are available, and if you run Linux with
 recent enough libc (2.7 or later) you can do this to create user mikem
 with password fred:

 % mkpasswd --method=SHA-512 --salt=SaltForFred fred
 $6$SaltForFred$emRLnSZatjAN8vGAwg5hJJ2IVbiM.ai0DwNOStp0TPfc0I9IgZ6hc4F00DefzvacVz9ftd7WU0GY7yMrQ7FY00

 % echo 'mikem
 User-Password=$6$SaltForFred$emRLnSZatjAN8vGAwg5hJJ2IVbiM.ai0DwNOStp0TPfc0I9IgZ6hc4F00DefzvacVz9ftd7WU0GY7yMrQ7FY00'
 users-file
 mkpasswd command comes with the whois package on Debian and Ubuntu
 systems. The salt is specified for example only, the command can create
 its own salts and does so by default.

 mkpasswd creates a password hash in the format that is compatible with
 /etc/shadow. Radiator then uses crypt() to check if the hash matches the
 submitted password.

 I've tried using Encrypted-Password = {SHA} but thats Netscape SHA and
 seems to be incompatible with SHA1.
 You can use goodies/sha.pl and goodies/ssha.pl to generate SHA and SSHA
 (Salted SHA) hashes. These are SHA1 only and the format is: Base64
 encoded hash value followed by 0 or more bytes of salt where 0 bytes
 means no salt is used.

 The command line utilities produced hex ouput so that's why it's not
 possible to use e.g. sha1sum output directly here.

 Thanks,
 Heikki

Thanks for the infos Heikki!
Are they included in the reference manual and I missed them? The section
that describes the different available password hashes would be a great
place to add them right next to the particular algorithm.

Are the crypt SHA-512 hashes portable to other OS Radiator runs on? I'd
prefer a hash that's checked using a portable Perl module like
Digest::SHA so I'm not depending on the OS.


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] suggested hash algorithm for passwords in text files

[Hartmaier Alexander]

On 2014-01-13 17:51, Heikki Vatiainen wrote:
 On 01/13/2014 06:26 PM, Hartmaier Alexander wrote:

 Are they included in the reference manual and I missed them? The
 section that describes the different available password hashes would
 be a great place to add them right next to the particular algorithm.
 $6$ and the general {crypt} formats are there. I made a note that
 $5$ is missing from the reference manual. The current list is in under
 Check items, section 13.1.1 User-Password, Password

 Is this the place you are thinking of?
Yes, exactly!


 Are the crypt SHA-512 hashes portable to other OS Radiator runs on?
 Might be for example, with FreeBSD but the FreeBSD manual states the
 salt has 8 character length limitation. Based on this there appear to be
 portability issues.

 I'd prefer a hash that's checked using a portable Perl module like
 Digest::SHA so I'm not depending on the OS.
 OpenLDAP seems to use {SHA256} and {SSHA256} for non-salted and salted
 attribute values (and for 384 and 512), so this might be the appropriate
 format for Radiator to use too.

 I'll see about adding these. Meanwhile, and also if patching is not
 desired, crypt formats should also work for Linux based servers with
 recent enough libcs.

 Thanks,
 Heikki

Patching is welcome! If you'd add those formats we would immediately
switch to using them.


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] suggested hash algorithm for passwords in text files

[Hartmaier Alexander]

From time to time I'm struggling with getting a new user account stored
in a file working.

As MD5 isn't recommended these days and we don't want to use some
vendor/product specific algorithm like the mysql or mssql ones I'm
looking for something like SHA256 or better.
Digest::SHA is a required module since version 4.10 but it's sha256 and
sha512 methods seem to be unused currently.
I've tried using Encrypted-Password = {SHA} but thats Netscape SHA and
seems to be incompatible with SHA1.


--
Best regards, Alexander Hartmaier

T-Systems Austria GesmbH
TSS Security Services
Network Security  Monitoring Engineer

phone: +43(0)57057-4320
fax: +43(0)57057-954320



***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Connecting to Oracle DB on non default port

[Hartmaier Alexander]

On 2014-01-06 21:26, rohan.henry @cwjamaica.com wrote:

Thanks Alexander.

I am able to connect to the remote server via the Linux prompt using:

sqlplus user/passwd@server_IP/SID

But can't seem to get it right in Radiator.

Rohan


On Fri, Jan 3, 2014 at 5:24 AM, Hartmaier Alexander 
alexander.hartma...@t-systems.atmailto:alexander.hartma...@t-systems.at 
wrote:
On 2014-01-03 00:14, rohan.henry @cwjamaica.comhttp://cwjamaica.com wrote:
Hello,

How is a non default port specified when connecting to a remote Oracle server? 
Thanks.

DBSource   dbi:oracle:server
DBUsername
DBAuth

Rohan
The Oracle InstantClient configuration is in tnsnames.ora, there you specify 
things like hostnames, ports and other settings. In Radiator you only use the 
name you gave the connection in tnsnames.ora.


The DBD::Oracle docs show you the possible ways to connect: 
https://metacpan.org/pod/DBD::Oracle#connect

Normally you'd specify the database name you've defined in tnsnames.ora:

DBSource dbi:Oracle:DBNAME

Note that Perl is case sensitive, you have to specify Oracle uppercase else DBI 
looks for a DBD::oracle module.


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Could not bind Server TACACSPLUS socket: Address already in use

[Hartmaier Alexander]

On 2014-01-07 13:43, Heikki Vatiainen wrote:
 On 01/03/2014 01:32 PM, Hartmaier Alexander wrote:

 we had the issue that our Radiator process was running but the TACACS
 socket on port 49 wasn't listening.
 It turned out that a restart caused this because either debians
 start-stop-daemon or the init script doesn't wait until the process is
 really gone and Radiator is started while the old process still has the
 socket open.
 A quick fix is a sleep 1; between stop and start in restart but I find
 that ugly.
 Do you have a better suggestion?
 The current version of init.d script uses '--retry 6' option with
 start-stop-daemon. The start-stop-daemon manual says about --retry and
 single option (timeout):

If timeout is specified instead of schedule, then the schedule
signal/timeout/KILL/timeout is used, where signal is  the  signal
specified with --signal.

 Default --signal is TERM. So the current init.d script should instruct
 start-stop-daemon to go as far as this (it should poll and exit as soon
 as the program exits):

kill -TERM $pid; sleep 6; kill -KILL $pid; sleep 6

 Does your script use --retry option? I'd think --retry should take care
 of the problem.

 Radiator logged 'ERR: Could not bind Server TACACSPLUS socket: Address
 already in use' to its logfile but still started, I'd suggest that such
 a fatal startup error results in Radiator dieing with this error message.

 What do you thing about that change?
 It sounds reasonable. I'll check about patching this.

 Thanks,
 Heikki

The current script on the affected box is
# $Id: linux-radiator.init,v 1.19 2011/05/18 23:49:34 mikem Exp $
from Radiator 4.9 which doesn't have the --retry option.

On our main radius server its
# $Id: linux-radiator.init,v 1.24 2012/12/11 22:17:43 mikem Exp mikem $
from Radiator 4.11 which has the --retry 6 start-stop-daemon option.

Good to know that it's already fixed.

I'll look into updating Radiator as I really like the 4.12 changes
regarding IPv6 and logging!


***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Connecting to Oracle DB on non default port

[Hartmaier Alexander]

On 2014-01-03 00:14, rohan.henry @cwjamaica.com wrote:
Hello,

How is a non default port specified when connecting to a remote Oracle server? 
Thanks.

DBSource   dbi:oracle:server
DBUsername
DBAuth

Rohan
The Oracle InstantClient configuration is in tnsnames.ora, there you specify 
things like hostnames, ports and other settings. In Radiator you only use the 
name you gave the connection in tnsnames.ora.




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

--
Best regards, Alexander Hartmaier

T-Systems Austria GesmbH
TSS Security Services
Network Security  Monitoring Engineer

phone: +43(0)57057-4320
fax: +43(0)57057-954320



***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Could not bind Server TACACSPLUS socket: Address already in use

[Hartmaier Alexander]

Hi guys,
we had the issue that our Radiator process was running but the TACACS
socket on port 49 wasn't listening.
It turned out that a restart caused this because either debians
start-stop-daemon or the init script doesn't wait until the process is
really gone and Radiator is started while the old process still has the
socket open.
A quick fix is a sleep 1; between stop and start in restart but I find
that ugly.
Do you have a better suggestion?

Radiator logged 'ERR: Could not bind Server TACACSPLUS socket: Address
already in use' to its logfile but still started, I'd suggest that such
a fatal startup error results in Radiator dieing with this error message.

What do you thing about that change?


--
Best regards, Alexander Hartmaier

T-Systems Austria GesmbH
TSS Security Services
Network Security  Monitoring Engineer

phone: +43(0)57057-4320
fax: +43(0)57057-954320



***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Enforce EAPTLS

[Hartmaier Alexander]

Hi Markus,
you didn't configure NoDefault, see in section 5.21.12 NoDefault in the 
Radiator Reference Manual for further details.

On 2013-12-20 11:30, Markus Moeller wrote:
Hi,

   I have a switch configure to do EAP TLS authentication and when I made an 
error in the config the following Access Request was sent to Radiator.


Code:   Access-Request
Identifier: 3
Authentic:  
7O2422714922213014717914619419518120619011
Attributes:
User-Name = 0021aa6e1103
User-Password = 
223118819912302461956eV211*:161
Service-Type = Call-Check
Framed-MTU = 1500
Called-Station-Id = 44-B4-A9-F9-42-A8
Calling-Station-Id = 00-21-DD-6F-35-03
Message-Authenticator = 27]/245205143J1473d7`218202bG
EAP-Key-Name =
NAS-Port-Type = Ethernet
NAS-Port = 50140
NAS-Port-Id = GigabitEthernet1/0/40
NAS-IP-Address = 10.7.1.2

But to my surprise Radiator sent back a Accept


Wed Dec 18 10:14:12 2013: DEBUG: Handling request with Handler 
'AuthType=radius', Identifier ''
Wed Dec 18 10:14:12 2013: DEBUG:  Deleting session for 0021aa6e1103, 10.7.1.2, 
50140
Wed Dec 18 10:14:12 2013: DEBUG: Handling with Radius::AuthFILE: EapTLS
Wed Dec 18 10:14:12 2013: DEBUG: Reading users file /opt/Radiator/users
Wed Dec 18 10:14:12 2013: DEBUG: Radius::AuthFILE looks for match with 
0021aa6e1103 [0021aa6e1103]
Wed Dec 18 10:14:12 2013: DEBUG: Radius::AuthFILE REJECT: No such user: 
0021aa6e1103 [0021aa6e1103]
Wed Dec 18 10:14:12 2013: DEBUG: Radius::AuthFILE looks for match with DEFAULT 
[0021aa6e1103]
Wed Dec 18 10:14:12 2013: DEBUG: Radius::AuthFILE ACCEPT: : DEFAULT 
[0021aa6e1103]
Wed Dec 18 10:14:12 2013: DEBUG: AuthBy FILE result: ACCEPT,
Wed Dec 18 10:14:12 2013: DEBUG: Packet dump:
*** Sending to 10.7.1.2 port 1645 
Code:   Access-Accept


My config is quite simple ( maybe too simple)

Handler AuthType=radius
  AuthBy EapTLS
  AuthLog LogToSyslog
/Handler


# EAPTLS authentication
AuthBy FILE
  Identifier EapTLS
  # the file is used to check usernames (assuming EAP-TLS certificate checks 
pass):
  Filename %D/users
  EAPType TLS
  # WLAN Additional Certificate Check
  EAPTLS_CertificateVerifyHook file:%D/hooks/eaptls_check.pl
  # WLAN root CAs
  EAPTLS_CAFile %{GlobalVar:CertsDir}/CA/ca.pem

  EAPTLS_CertificateType PEM
  # Radiator Cert
  EAPTLS_CertificateFile %{GlobalVar:CertsDir}/server/my_server_cert.pem
  # Radiator private key
  EAPTLS_PrivateKeyFile %{GlobalVar:CertsDir}/server/my_server_cert.key

  EAPTLS_MaxFragmentSize 1000

  EAPTLS_CRLCheck
  EAPTLS_CRLFile %{GlobalVar:CertsDir}/crls/ca.pem

  AutoMPPEKeys
/AuthBy


What do I need to add that a Radius request without a EAP-Message does not get 
accepted ?


Thank you
Markus



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

--
Best regards, Alexander Hartmaier

T-Systems Austria GesmbH
TSS Security Services
Network Security  Monitoring Engineer

phone: +43(0)57057-4320
fax: +43(0)57057-954320



***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Enforce EAPTLS

[Hartmaier Alexander]

Ah, gotcha!

You need to change your Handler so it only matches EAP requests, for
example:

Handler AuthType=radius, EAP-Message=/.+/


On 2013-12-20 13:35, Markus Moeller wrote:
 Hi Alexander,
  
But I need the default for the case when I get a successful EAPTLS
 exchange the user file is still checked and to avoid adding all users
 I need a DEFAULT don’t I ?
  
 Markus
  
  
 *From:* Hartmaier Alexander mailto:alexander.hartma...@t-systems.at
 *Sent:* Friday, December 20, 2013 10:52 AM
 *To:* radiator@open.com.au mailto:radiator@open.com.au
 *Subject:* Re: [RADIATOR] Enforce EAPTLS
  
 Hi Markus,
 you didn't configure NoDefault, see in section 5.21.12 NoDefault in
 the Radiator Reference Manual for further details.

 On 2013-12-20 11:30, Markus Moeller wrote:

 Hi,

  

I have a switch configure to do EAP TLS authentication and when I
 made an error in the config the following Access Request was sent to
 Radiator.

  

  

 Code:   Access-Request

 Identifier: 3

 Authentic: 
 7O2422714922213014717914619419518120619011

 Attributes:

 User-Name = 0021aa6e1103

 User-Password =
 223118819912302461956eV211*:161

 Service-Type = Call-Check

 Framed-MTU = 1500

 Called-Station-Id = 44-B4-A9-F9-42-A8

 Calling-Station-Id = 00-21-DD-6F-35-03

 Message-Authenticator =
 27]/245205143J1473d7`218202bG

 EAP-Key-Name =

 NAS-Port-Type = Ethernet

 NAS-Port = 50140

 NAS-Port-Id = GigabitEthernet1/0/40

 NAS-IP-Address = 10.7.1.2

  

 But to my surprise Radiator sent back a Accept

  

  

 Wed Dec 18 10:14:12 2013: DEBUG: Handling request with Handler
 'AuthType=radius', Identifier ''

 Wed Dec 18 10:14:12 2013: DEBUG:  Deleting session for 0021aa6e1103,
 10.7.1.2, 50140

 Wed Dec 18 10:14:12 2013: DEBUG: Handling with Radius::AuthFILE: EapTLS

 Wed Dec 18 10:14:12 2013: DEBUG: Reading users file /opt/Radiator/users

 Wed Dec 18 10:14:12 2013: DEBUG: Radius::AuthFILE looks for match
 with 0021aa6e1103 [0021aa6e1103]

 Wed Dec 18 10:14:12 2013: DEBUG: Radius::AuthFILE REJECT: No such
 user: 0021aa6e1103 [0021aa6e1103]

 Wed Dec 18 10:14:12 2013: DEBUG: Radius::AuthFILE looks for match
 with DEFAULT [0021aa6e1103]

 Wed Dec 18 10:14:12 2013: DEBUG: Radius::AuthFILE ACCEPT: : DEFAULT
 [0021aa6e1103]

 Wed Dec 18 10:14:12 2013: DEBUG: AuthBy FILE result: ACCEPT,

 Wed Dec 18 10:14:12 2013: DEBUG: Packet dump:

 *** Sending to 10.7.1.2 port 1645 

 Code:   Access-Accept

  

  

 My config is quite simple ( maybe too simple)

  

 Handler AuthType=radius

   AuthBy EapTLS

   AuthLog LogToSyslog

 /Handler

  

  

 # EAPTLS authentication

 AuthBy FILE

   Identifier EapTLS

   # the file is used to check usernames (assuming EAP-TLS certificate
 checks pass):

   Filename %D/users

   EAPType TLS

   # WLAN Additional Certificate Check

   EAPTLS_CertificateVerifyHook file:%D/hooks/eaptls_check.pl

   # WLAN root CAs

   EAPTLS_CAFile %{GlobalVar:CertsDir}/CA/ca.pem

  

   EAPTLS_CertificateType PEM

   # Radiator Cert

   EAPTLS_CertificateFile %{GlobalVar:CertsDir}/server/my_server_cert.pem

   # Radiator private key

   EAPTLS_PrivateKeyFile %{GlobalVar:CertsDir}/server/my_server_cert.key

  

   EAPTLS_MaxFragmentSize 1000

  

   EAPTLS_CRLCheck

   EAPTLS_CRLFile %{GlobalVar:CertsDir}/crls/ca.pem

  

   AutoMPPEKeys

 /AuthBy

  

  

 What do I need to add that a Radius request without a EAP-Message
 does not get accepted ?  

  

  

 Thank you

 Markus



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

 -- 
 Best regards, Alexander Hartmaier

 T-Systems Austria GesmbH
 TSS Security Services
 Network Security  Monitoring Engineer

 phone: +43(0)57057-4320
 fax: +43(0)57057-954320



 ***
 T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
 Handelsgericht Wien, FN 79340b
 ***
 Notice: This e-mail contains information that is confidential and may
 be privileged.
 If you are not the intended recipient, please notify the sender and then
 delete this e-mail immediately.
 ***

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

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

Re: [RADIATOR] IPv6 enhancements in current patches: IPV6_V6ONLY and IPv6 CIDR clients

[Hartmaier Alexander]

On 2013-08-23 10:35, Heikki Vatiainen wrote:
 On 08/22/2013 05:59 PM, Alexander Hartmaier wrote:

 I hope the reference manual was updated to reflect this feature as well.
 Yes. The plan is to also have a separate section in the reference manual
 that talks about IPv6 in more detail. It will have information about
 IPv6 support - address binding, IPv6 related attributes, IPv6 CIDR
 clients, required modules, RFCs, etc. - all gathered in one place.
I've just read the IPv6 section in the 4.12.1 reference manual after
installing 4.12.1 on a new RHEL6 box which has IPv6 support disabled via
'alias ipv6 off' and 'options ipv6 disable=1' in /etc/modprobe.d/local.conf.

On startup Radiator logs: 'INFO: This system is IPv6 capable. IPv6
capability provided by: core' although the Socket6 module isn't
installed because its tests fail because IPv6 support is disabled in the
Linux kernel.
But the manual says 'Note: Currently IPv6 support requires Socket6.pm
Perl module.'. Which one is correct, the manual or the log message?
The Perl version is 5.16.3 compiled on the box using perlbrew.

The very first sentence doesn't mention TACACS+, does it support IPv6
too or not?
Please add this info.

BR Alex



 Thanks,
 Heikki

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



***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] TACACS peer name

[Hartmaier Alexander]

On 2013-11-27 23:24, Heikki Vatiainen wrote:
 On 11/27/2013 01:30 PM, Hartmaier Alexander wrote:

 On 11/25/2013 05:24 PM, Fabio Prina wrote:
 Mon Nov 25 14:21:25 2013: ERR: Could not get peer name on
 TacacsplusConnection socket: Transport endpoint is not connected
 Mon Nov 25 14:21:25 2013: DEBUG: TacacsplusConnection disconnected from :
 We have the same messages in our logs and it might be connected to my
 thread about 'Cisco NX-OS TACACS+ problems'.
 I tried adding a sleep between accept and getpeername calls and
 disconnecting while radiusd was sleeping, but that did not cause it. In
 other words, a quick disconnect before getpeername did not make
 getpeername fail so it might be caused by something that happens during
 accept.

 Do you have FarmSize enabled? I see accept is called a bit differently
 for ServerTACACSPLUS than for the other TCP stream servers.
We don't have FarmSize activated.

 Thanks,
 Heikki




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] TACACS peer name

[Hartmaier Alexander]

On 2013-11-26 10:47, Heikki Vatiainen wrote:
 On 11/25/2013 05:24 PM, Fabio Prina wrote:

 In my TACACS trace 4 logs I see, not so few, rows like:

 Mon Nov 25 14:21:25 2013: ERR: Could not get peer name on
 TacacsplusConnection socket: Transport endpoint is not connected
 Mon Nov 25 14:21:25 2013: DEBUG: TacacsplusConnection disconnected from :
We have the same messages in our logs and it might be connected to my
thread about 'Cisco NX-OS TACACS+ problems'.

 Do you know why and how I can fix it ?
 The call to get peer name is done immediately after a new TCP connection
 is accepted from the listen socket pending connection queue.

 In other words, the call to get peer name, IP address and other info, is
 about the first thing that is done for the new incoming TCP connection.

 Do you have IPv6 connections coming in? What else could cause the listen
 socket to indicate incoming connection? Which Radiator version, Perl
 version and operating system you are using?

 Thanks,
 Heikki




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radius domain only auth, with password='cisco'

[Hartmaier Alexander]

We for example have a pair of Cisco IOS routers with multiple vrf's
(usually one per customer) where client vpn's terminate, one xauth group
per customer and this authorization requests makes sure that a user of
customer1 can't connect with another group.

On 2013-11-07 18:57, Michael wrote:
 what i do understand is that they are being rejected anyways because i
 have no config for it. they're all rejected. what's the point of
 having requests like these being rejected.  it's true i don't
 understand what they are for, but at the same time they're not
 working.  so how are they important?



 On 07/11/13 12:34 PM, Hartmaier Alexander wrote:
 It seems you don't understand the importance of those *authorization*
 requests: without them every user could authenticate against *every*
 xauth group you've configured!

 On 2013-11-07 18:20, Michael wrote:
 so you are talking about actually authenticating these requests
 successfully where i'm looking at stopping them.  I guess i could just
 reject all Service-Type=Outbound-User but i was kinda just hoping to
 stop the requests all together. Thanks though.  maybe i will just make
 a handler config to just reject them.


 On 07/11/13 11:02 AM, Hartmaier Alexander wrote:
 My memory might be wrong on the order of requests.
 Our radiator config is as follows:

 # handler for vpn group-users
 Handler Realm=group1, Service-Type=Outbound-User
 # those group users are also stored in our database but with a
 different
 type, all have the password 'cisco'
 # the reply attributes are group specific, e.g.:

 Session-Timeout=0
 Framed-IP-Netmask=255.255.255.255
 cisco-avpair=ipsec:dns-servers=1.2.3.4 1.2.3.5
 cisco-avpair=ipsec:addr-pool=group1_pool

 cisco-avpair=ipsec:tunnel-password=foobarbaz
 cisco-avpair=ipsec:default-domain=customer.tld
 # these control the Cisco IPSec 5.x client settings
 cisco-avpair=ipsec:firewall=0
 cisco-avpair=ipsec:include-local-lan=0
 cisco-avpair=ipsec:save-password=0

 /Handler

 # handler for vpn users
 Handler Realm=yourrealm
 # those group users are also stored in our database but with a
 different
 type

 The reply attributes contain some of the above, not sure which one
 overrides the other

 /Handler

 On 2013-11-07 15:22, Michael wrote:
 i don't understand it. The requests i'm speaking of all come before
 the user auth.  not after.  And, they of course are all being
 rejected
 because we don't even know what they are, nor use them, nor need
 them.

 On 07/11/13 03:40 AM, Hartmaier Alexander wrote:
 Yes, a Cisco IOS router configured to terminate IPSec IKEv1
 client vpn
 will send such an authorization request after the user auth to
 check if
 the user is allowed to connect using this group.

 On 2013-11-07 06:04, Hugh Irvine wrote:
 Hello Michael -

 This is configured on the Cisco box - you will need to ask your
 network people to turn it off.

 regards

 Hugh


 On 7 Nov 2013, at 10:05, Michael ri...@vianet.ca wrote:

 i'm looking to stop it. not set it up.  i'm not sure what had
 enabled/configured it to start happening.  I guess this is
 probably
 the wrong place to ask.

 On 06/11/13 04:56 PM, Hugh Irvine wrote:
 Hello Michael -

 This sounds like Cisco VPDN tunnelling.

 This example is from the standard “users” file in the Radiator
 distribution:


 # This example shows how to configure a Cisco VPDN circuit:
 open.com.au User-Password=cisco, Service-Type=Outbound-User
cisco-avpair = vpdn:tunnel-id=cca-gw,
cisco-avpair = vpdn:ip-addresses=1.2.3.4,
cisco-avpair = vpdn:nas-password=pw,
cisco-avpair = vpdn:gw-password=pw”


 regards

 Hugh


 On 7 Nov 2013, at 04:56, Michael ri...@vianet.ca wrote:

 Has anyone ever seen a situation where, for every authentication
 attempt
 to a radiator system from a cisco device, there is an
 authentication
 attempt right before it that appears to be:

 - a domain (the username with the 'username@' part stripped
 off).
 - plain text password is always 'cisco'.
 - Service-Type = Outbound-User

 if I remove this line from the cisco lns:
 aaa authorization network TEST group TEST
 ...the extra auth attempts stop, but then my radius network
 static
 profiles don't work, so it's not a solution but it narrows down
 the problem.

 my auth requests for the radiator system are essentially doubled
 due to
 this.  This only started happening recently.  Network guys
 sometimes are
 like a ticking time bomb and asking them can cause an explosion
 so i
 thought i would ask here.


 Mike
 ___
 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 etc.
 Full

Re: [RADIATOR] Radius domain only auth, with password='cisco'

[Hartmaier Alexander]

Yes, a Cisco IOS router configured to terminate IPSec IKEv1 client vpn
will send such an authorization request after the user auth to check if
the user is allowed to connect using this group.

On 2013-11-07 06:04, Hugh Irvine wrote:
 Hello Michael -

 This is configured on the Cisco box - you will need to ask your network 
 people to turn it off.

 regards

 Hugh


 On 7 Nov 2013, at 10:05, Michael ri...@vianet.ca wrote:

 i'm looking to stop it. not set it up.  i'm not sure what had 
 enabled/configured it to start happening.  I guess this is probably the 
 wrong place to ask.

 On 06/11/13 04:56 PM, Hugh Irvine wrote:
 Hello Michael -

 This sounds like Cisco VPDN tunnelling.

 This example is from the standard “users” file in the Radiator distribution:


 # This example shows how to configure a Cisco VPDN circuit:
 open.com.au User-Password=cisco, Service-Type=Outbound-User
 cisco-avpair = vpdn:tunnel-id=cca-gw,
 cisco-avpair = vpdn:ip-addresses=1.2.3.4,
 cisco-avpair = vpdn:nas-password=pw,
 cisco-avpair = vpdn:gw-password=pw”


 regards

 Hugh


 On 7 Nov 2013, at 04:56, Michael ri...@vianet.ca wrote:

 Has anyone ever seen a situation where, for every authentication attempt
 to a radiator system from a cisco device, there is an authentication
 attempt right before it that appears to be:

 - a domain (the username with the 'username@' part stripped off).
 - plain text password is always 'cisco'.
 - Service-Type = Outbound-User

 if I remove this line from the cisco lns:
 aaa authorization network TEST group TEST
 ...the extra auth attempts stop, but then my radius network static
 profiles don't work, so it's not a solution but it narrows down the 
 problem.

 my auth requests for the radiator system are essentially doubled due to
 this.  This only started happening recently.  Network guys sometimes are
 like a ticking time bomb and asking them can cause an explosion so i
 thought i would ask here.


 Mike
 ___
 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 etc.
 Full source on Unix, 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 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



***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radius domain only auth, with password='cisco'

[Hartmaier Alexander]

My memory might be wrong on the order of requests.
Our radiator config is as follows:

# handler for vpn group-users
Handler Realm=group1, Service-Type=Outbound-User
# those group users are also stored in our database but with a different
type, all have the password 'cisco'
# the reply attributes are group specific, e.g.:

Session-Timeout=0
Framed-IP-Netmask=255.255.255.255
cisco-avpair=ipsec:dns-servers=1.2.3.4 1.2.3.5
cisco-avpair=ipsec:addr-pool=group1_pool

cisco-avpair=ipsec:tunnel-password=foobarbaz
cisco-avpair=ipsec:default-domain=customer.tld
# these control the Cisco IPSec 5.x client settings
cisco-avpair=ipsec:firewall=0
cisco-avpair=ipsec:include-local-lan=0
cisco-avpair=ipsec:save-password=0

/Handler

# handler for vpn users
Handler Realm=yourrealm
# those group users are also stored in our database but with a different
type

The reply attributes contain some of the above, not sure which one
overrides the other

/Handler

On 2013-11-07 15:22, Michael wrote:
 i don't understand it. The requests i'm speaking of all come before
 the user auth.  not after.  And, they of course are all being rejected
 because we don't even know what they are, nor use them, nor need them.

 On 07/11/13 03:40 AM, Hartmaier Alexander wrote:
 Yes, a Cisco IOS router configured to terminate IPSec IKEv1 client vpn
 will send such an authorization request after the user auth to check if
 the user is allowed to connect using this group.

 On 2013-11-07 06:04, Hugh Irvine wrote:
 Hello Michael -

 This is configured on the Cisco box - you will need to ask your
 network people to turn it off.

 regards

 Hugh


 On 7 Nov 2013, at 10:05, Michael ri...@vianet.ca wrote:

 i'm looking to stop it. not set it up.  i'm not sure what had
 enabled/configured it to start happening.  I guess this is probably
 the wrong place to ask.

 On 06/11/13 04:56 PM, Hugh Irvine wrote:
 Hello Michael -

 This sounds like Cisco VPDN tunnelling.

 This example is from the standard “users” file in the Radiator
 distribution:


 # This example shows how to configure a Cisco VPDN circuit:
 open.com.au User-Password=cisco, Service-Type=Outbound-User
  cisco-avpair = vpdn:tunnel-id=cca-gw,
  cisco-avpair = vpdn:ip-addresses=1.2.3.4,
  cisco-avpair = vpdn:nas-password=pw,
  cisco-avpair = vpdn:gw-password=pw”


 regards

 Hugh


 On 7 Nov 2013, at 04:56, Michael ri...@vianet.ca wrote:

 Has anyone ever seen a situation where, for every authentication
 attempt
 to a radiator system from a cisco device, there is an authentication
 attempt right before it that appears to be:

 - a domain (the username with the 'username@' part stripped off).
 - plain text password is always 'cisco'.
 - Service-Type = Outbound-User

 if I remove this line from the cisco lns:
 aaa authorization network TEST group TEST
 ...the extra auth attempts stop, but then my radius network static
 profiles don't work, so it's not a solution but it narrows down
 the problem.

 my auth requests for the radiator system are essentially doubled
 due to
 this.  This only started happening recently.  Network guys
 sometimes are
 like a ticking time bomb and asking them can cause an explosion so i
 thought i would ask here.


 Mike
 ___
 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 etc.
 Full source on Unix, 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 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


 ***

 T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
 Handelsgericht Wien, FN 79340b
 ***

 Notice: This e-mail contains information that is confidential and may
 be privileged.
 If you are not the intended recipient, please notify the sender and then
 delete this e-mail immediately.
 ***

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



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

Re: [RADIATOR] Radius domain only auth, with password='cisco'

[Hartmaier Alexander]

It seems you don't understand the importance of those *authorization*
requests: without them every user could authenticate against *every*
xauth group you've configured!

On 2013-11-07 18:20, Michael wrote:
 so you are talking about actually authenticating these requests
 successfully where i'm looking at stopping them.  I guess i could just
 reject all Service-Type=Outbound-User but i was kinda just hoping to
 stop the requests all together. Thanks though.  maybe i will just make
 a handler config to just reject them.


 On 07/11/13 11:02 AM, Hartmaier Alexander wrote:
 My memory might be wrong on the order of requests.
 Our radiator config is as follows:

 # handler for vpn group-users
 Handler Realm=group1, Service-Type=Outbound-User
 # those group users are also stored in our database but with a different
 type, all have the password 'cisco'
 # the reply attributes are group specific, e.g.:

 Session-Timeout=0
 Framed-IP-Netmask=255.255.255.255
 cisco-avpair=ipsec:dns-servers=1.2.3.4 1.2.3.5
 cisco-avpair=ipsec:addr-pool=group1_pool

 cisco-avpair=ipsec:tunnel-password=foobarbaz
 cisco-avpair=ipsec:default-domain=customer.tld
 # these control the Cisco IPSec 5.x client settings
 cisco-avpair=ipsec:firewall=0
 cisco-avpair=ipsec:include-local-lan=0
 cisco-avpair=ipsec:save-password=0

 /Handler

 # handler for vpn users
 Handler Realm=yourrealm
 # those group users are also stored in our database but with a different
 type

 The reply attributes contain some of the above, not sure which one
 overrides the other

 /Handler

 On 2013-11-07 15:22, Michael wrote:
 i don't understand it. The requests i'm speaking of all come before
 the user auth.  not after.  And, they of course are all being rejected
 because we don't even know what they are, nor use them, nor need them.

 On 07/11/13 03:40 AM, Hartmaier Alexander wrote:
 Yes, a Cisco IOS router configured to terminate IPSec IKEv1 client vpn
 will send such an authorization request after the user auth to
 check if
 the user is allowed to connect using this group.

 On 2013-11-07 06:04, Hugh Irvine wrote:
 Hello Michael -

 This is configured on the Cisco box - you will need to ask your
 network people to turn it off.

 regards

 Hugh


 On 7 Nov 2013, at 10:05, Michael ri...@vianet.ca wrote:

 i'm looking to stop it. not set it up.  i'm not sure what had
 enabled/configured it to start happening.  I guess this is probably
 the wrong place to ask.

 On 06/11/13 04:56 PM, Hugh Irvine wrote:
 Hello Michael -

 This sounds like Cisco VPDN tunnelling.

 This example is from the standard “users” file in the Radiator
 distribution:


 # This example shows how to configure a Cisco VPDN circuit:
 open.com.au User-Password=cisco, Service-Type=Outbound-User
   cisco-avpair = vpdn:tunnel-id=cca-gw,
   cisco-avpair = vpdn:ip-addresses=1.2.3.4,
   cisco-avpair = vpdn:nas-password=pw,
   cisco-avpair = vpdn:gw-password=pw”


 regards

 Hugh


 On 7 Nov 2013, at 04:56, Michael ri...@vianet.ca wrote:

 Has anyone ever seen a situation where, for every authentication
 attempt
 to a radiator system from a cisco device, there is an
 authentication
 attempt right before it that appears to be:

 - a domain (the username with the 'username@' part stripped off).
 - plain text password is always 'cisco'.
 - Service-Type = Outbound-User

 if I remove this line from the cisco lns:
 aaa authorization network TEST group TEST
 ...the extra auth attempts stop, but then my radius network static
 profiles don't work, so it's not a solution but it narrows down
 the problem.

 my auth requests for the radiator system are essentially doubled
 due to
 this.  This only started happening recently.  Network guys
 sometimes are
 like a ticking time bomb and asking them can cause an explosion
 so i
 thought i would ask here.


 Mike
 ___
 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 etc.
 Full source on Unix, 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 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

 ***


 T-Systems Austria

Re: [RADIATOR] CRL reload question

[Hartmaier Alexander]

This is a more human friendly output:

/$path/to/perl/used/by/radiator/perl -MNet::SSLeay -E 'say
Net::SSLeay::SSLeay_version()'

On 2013-10-30 23:25, Markus Moeller wrote:
 Hi Heikki,

Thank you for that.  Despite my attempts to use the latest static openssl
 library I used an old one :-(. I will retest.

 Markus

 -Original Message-
 From: Heikki Vatiainen
 Sent: Wednesday, October 30, 2013 9:20 PM
 To: Markus Moeller ; radiator@open.com.au
 Subject: Re: [RADIATOR] CRL reload question

 On 10/30/2013 10:39 PM, Markus Moeller wrote:

  I have linked it statically to avoid mixup with system libraries. There
 is no way to check it in another way is there ?
 If you have Net::SSLeay newer than 1.42, try putting this in Radiator
 configuration:

 StartupHook sub { use Net::SSLeay; main::log($main::LOG_INFO, \
   SSL version:  . \
   sprintf(0x%x, Net::SSLeay::SSLeay())); }

 You should find something like this from Radiator logs:

INFO: SSL version: 0x1000100f

 See this for more info:
 http://search.cpan.org/~mikem/Net-SSLeay-1.55/lib/Net/SSLeay.pod#Low_level_API:_Version_related_functions

 Thanks,
 Heikki


 Markus

 -Original Message- From: Heikki Vatiainen
 Sent: Wednesday, October 30, 2013 5:11 PM
 To: Markus Moeller ; radiator@open.com.au
 Subject: Re: [RADIATOR] CRL reload question

 On 10/29/2013 12:41 AM, Markus Moeller wrote:

   I still get the same error with openssl 1.0.1. The CRL on disk is new,
 but radiator says CRL is expired. Radiator also gives a reload CRL error
 saying the CRL alredy exists.
 Hello Markus,

 can you do one more test? Check with 'ldd
 /path/to/auto/Net/SSLeay/SSLeay.so' that it links against the OpenSSL
 libs you expect it to.

 Thanks,
 Heikki

 Mon Oct 28 22:15:22 2013: DEBUG: (Re)loading CRL file
 '/opt/radiator/etc/certs/crls/User_CA_1.pem'
 Mon Oct 28 22:15:22 2013: ERR: Failed to add CRL file
 '/opt/radiator/etc/certs/crls/User_CA_1.pem': error:0B07D065:x509
 certificate routines:X509_STORE_add_crl:cert already in hash table
 Mon Oct 28 22:15:22 2013: DEBUG: (Re)loading CRL file
 '/opt/radiator/etc/certs/crls/User_CA_2.pem'
 Mon Oct 28 22:15:22 2013: ERR: Failed to add CRL file
 '/opt/radiator/etc/certs/crls/User_CA_2.pem': error:0B07D065:x509
 certificate routines:X509_STORE_add_crl:cert already in hash table
 Mon Oct 28 22:15:22 2013: DEBUG: (Re)loading CRL file
 '/opt/radiator/etc/certs/crls/User_CA_4.pem'
 Mon Oct 28 22:15:22 2013: ERR: Failed to add CRL file
 '/opt/radiator/etc/certs/crls/User_CA_4.pem': error:0B07D065:x509
 certificate routines:X509_STORE_add_crl:cert already in hash table
 Mon Oct 28 22:20:52 2013: INFO: EAP TLS certificate verification failed:
 CRL has expired,  19868: 1 - error:140890B2:SSL
 routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
 Mon Oct 28 22:21:23 2013: INFO: EAP TLS certificate verification failed:
 CRL has expired,  19868: 1 - error:140890B2:SSL
 routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned

 # ls -al User_CA_2.pem
 -rwxrwxrwx   1 root root   70699 Oct 28 21:55 User_CA_2.pem

 # /usr/sfw/bin/openssl crl -in User_CA_2.pem -noout -lastupdate
 -nextupdate
 lastUpdate=Oct 28 19:26:37 2013 GMT
 nextUpdate=Nov 11 19:26:37 2013 GMT



 Markus

 -Original Message- From: Markus Moeller
 Sent: Monday, September 30, 2013 10:50 PM
 To: Heikki Vatiainen ; radiator@open.com.au
 Subject: Re: [RADIATOR] CRL reload question

 Hi Heikki,

   OK I'll try with a later 1.x version.

 Thank you
 Markus

 -Original Message- From: Heikki Vatiainen
 Sent: Monday, September 30, 2013 10:18 PM
 To: radiator@open.com.au
 Subject: Re: [RADIATOR] CRL reload question

 On 09/29/2013 04:52 PM, Markus Moeller wrote:

I would  expect  something like this:

 If error already in hashtable

 $self-log($main::LOG_ERR, Free old entray and add new CRL;

 Hello Markus,

 we have not looked at CRL reloading lately so I can not tell if the new
 functions would help with CRL reloading. However, a quick look at
 OpenSSL shows the CRL lookups in X509_STORE_add_crl are done differently
 in 1.x versions than e.g., in 0.9.8x. Also, these changes between 0.9.x
 and 1.0.0 look promising (OpenSSL changelog):

  *) Allow multiple CRLs to exist in an X509_STORE with matching issuer
 names.
 Modify get_crl() to find a valid (unexpired) CRL if possible.
 [Steve Henson]

  *) New function X509_CRL_match() to check if two CRLs are identical.
 Normally
 this would be called X509_CRL_cmp() but that name is already used by
 a function that just compares CRL issuer names. Cache several CRL
 extensions in X509_CRL structure and cache CRLDP in X509.
 [Steve Henson]

 If you plan to test this, can you see if you get different results with
 OpenSSL 1.0.x versions than 0.9.8x?

 Thanks,
 Heikki

 loop over objects
 my $idx = 0 ?
 for (i = $idx ; i $cert_store-num; i++) {
my $obj - $cert_store-data[i];
if (obj-data.crl == $crl-data.crl) {

Re: [RADIATOR] [*** Newsletter ***] Re: [*** Newsletter ***] Re: Cisco NX-OS TACACS+ problems

[Hartmaier Alexander]

On 2013-10-18 13:07, Heikki Vatiainen wrote:
 On 10/18/2013 12:14 PM, Alexander Hartmaier wrote:

 The requests are sent to two Radiator servers forming a faiover pair
 which both have the same TACACS key.
 It only happens from time to time, the authentication and accouting
 requests usually work.
 Have you tried with SingleSession option? This sets the
 TAC_PLUS_SINGLE_CONNECT_FLAG flag as described in
 http://tools.ietf.org/html/draft-grant-tacacs-02

That's a good pointer, thanks!
According to the Radiator ref.pdf it defaults to 1 (enabled) (we're
running 4.11 + patches), should I try to disable it? Can this be done
for some clients only too?


 Thanks,
 Heikki




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator