[RADIATOR] Radiator mailing list migration
Hello list members, Radiator mailing lists and list archives are migrating to a new server soon. This requires no action from you. A message will be posted through the migrated list when the operation has finished. This should happen later today. The current mailing list address, radiator@open.com.au, will become an alias for the Radiator list address and it will continue to work until further notice. The new list address will be radia...@lists.open.com.au which is preferred after the migration. The migrated lists will be running on https://lists.open.com.au 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
Re: [RADIATOR] EAP-TTLS, MSCHAPV2 - Bad Password
Hello Bryce,
If you are using MSCHAPv2 inside EAP-TTLS, you are not allowed to
rewrite username since username field is part of password calculation.
Also if you are using MSHCAPv2, then NAS does not send clear text
password so Radiator is not able to log it.
Best Regards,
Sami
On 14/10/16 20:32, br...@truespeed.ca wrote:
Hello,
We are setting up test Wireless network so that our client radio will
authenticate against our Platypus database. The issue is that our
client radios are being rejected with a Bad Password message (We have
checked and the passwords are correct). But if we set up radius so
that the client radio authenticates against a flat file (WifiClients),
it works. One thing that I have noticed in our Failure log is that
the bad password isn’t shown. I have pasted my config below and
attached it along with part of our logfile and Failurelog.
We are using Radiator version 4.16
We are using Ubiquiti PowerBeams and NanoBeams in our test network.
LogDir /var/log/radius
DbDir /etc/radiator
AuthPort 1645,1812
AcctPort 1646,1813
Trace 4
#
##NAS Client IPs ##
#
##Test NAS for Wireless
Secret x
Identifier AP
DupInterval 0
#
## Authorization##
#
#Authorization Using Flat File
Identifier WifiClients
Filename /etc/radiator/WifiClients
#Authorization using Radius Application
Identifier CheckPLATYPUS
DBSource dbi:Sybase:Platypus
DBUsernamexxx
DBAuthxxx
AuthCheck SELECT id,UserName,case Attribute when
'Cleartext-Password' then 'User-Password' else Attribute end,Value,op
FROM freeradius_service_radcheck WHERE Username = ? ORDER BY id
AuthReply SELECT id,UserName,Attribute,Value,op FROM
freeradius_service_radreply WHERE Username = ? ORDER BY id
AuthGroupCheck SELECT
freeradius_service_radgroupcheck.id,freeradius_service_radgroupcheck.GroupName,freeradius_service_radgroupcheck.Attribute,freeradius_service_radgroupcheck.Value,freeradius_service_radgroupcheck.op
FROM freeradius_service_radgroupcheck,freeradius_service_radusergroup
WHERE freeradius_service_radusergroup.Username = ? AND
freeradius_service_radusergroup.GroupName =
freeradius_service_radgroupcheck.GroupName ORDER BY
freeradius_service_radgroupcheck.id
AuthGroupReply SELECT
freeradius_service_radgroupreply.id,freeradius_service_radgroupreply.GroupName,freeradius_service_radgroupreply.Attribute,freeradius_service_radgroupreply.Value,freeradius_service_radgroupreply.op
FROM freeradius_service_radgroupreply,freeradius_service_radusergroup
WHERE freeradius_service_radusergroup.Username = ? AND
freeradius_service_radusergroup.GroupName =
freeradius_service_radgroupreply.GroupName ORDER BY
freeradius_service_radgroupreply.id
AcctStartQuery INSERT into freeradius_service_radacct (AcctSessionId,
AcctUniqueId, UserName, GroupName, Realm, NASIPAddress, NASPort,
NASPortType, AcctStartTime, AcctStopTime,AcctSessionTime,
AcctAuthentic, ConnectInfo_start, ConnectInfo_stop, AcctInputOctets,
AcctOutputOctets, CalledStationId, CallingStationId,
AcctTerminateCause, ServiceType, FramedProtocol, FramedIPAddress,
AcctStartDelay, AcctStopDelay, XAscendSessionSvrKey)
VALUES('%{Acct-Session-Id}', '%{Acct-Unique-Session-Id}', %0, null,
'%{Realm}', '%{NAS-IP-Address}', '%{NAS-Port}', '%{NAS-Port-Type}',
'%J', '1900-01-01 00:00:00', '0', '%{Acct-Authentic}',
'%{Connect-Info}', '', '0', '0', '%{Called-Station-Id}', '', '',
'%{Service-Type}', '%{Framed-Protocol}', '%{Framed-IP-Address}',
'%{Acct-Delay-Time}', '0', null)
AcctUpdateQuery UPDATE freeradius_service_radacct SET
FramedIPAddress = '%{Framed-IP-Address}', AcctSessionTime =
'%{Acct-Session-Time}', AcctInputOctets =
cast(((0%{Acct-Input-Gigawords} * 4294967296) + %{Acct-Input-Octets})
as numeric(18,0)), AcctOutputOctets = cast(((0%{Acct-Output-Gigawords}
* 4294967296) + %{Acct-Output-Octets}) as numeric(18,0)) WHERE
AcctSessionId = '%{Acct-Session-Id}' AND UserName = %0 AND
NASIPAddress= '%{NAS-IP-Address}'
AcctStopQuery UPDATE freeradius_service_radacct SET AcctStopTime =
'%J', AcctSessionTime = '%{Acct-Session-Time}', AcctInputOctets =
cast(((0%{Acct-Input-Gigawords} * 4294967296)
[RADIATOR] EAP-TTLS, MSCHAPV2 - Bad Password
Hello,
We are setting up test Wireless network so that our client radio will
authenticate against our Platypus database. The issue is that our client
radios are being rejected with a Bad Password message (We have checked and
the passwords are correct). But if we set up radius so that the client
radio authenticates against a flat file (WifiClients), it works. One thing
that I have noticed in our Failure log is that the bad password isn't shown.
I have pasted my config below and attached it along with part of our logfile
and Failurelog.
We are using Radiator version 4.16
We are using Ubiquiti PowerBeams and NanoBeams in our test network.
LogDir /var/log/radius
DbDir /etc/radiator
AuthPort 1645,1812
AcctPort 1646,1813
Trace 4
#
##NAS Client IPs ##
#
##Test NAS for Wireless
Secret x
Identifier AP
DupInterval 0
#
##Authorization##
#
#Authorization Using Flat File
Identifier WifiClients
Filename/etc/radiator/WifiClients
#Authorization using Radius Application
IdentifierCheckPLATYPUS
DBSource dbi:Sybase:Platypus
DBUsernamexxx
DBAuthxxx
AuthCheck SELECT id,UserName,case Attribute when
'Cleartext-Password' then 'User-Password' else Attribute end,Value,op FROM
freeradius_service_radcheck WHERE Username = ? ORDER BY id
AuthReply SELECT id,UserName,Attribute,Value,op FROM
freeradius_service_radreply WHERE Username = ? ORDER BY id
AuthGroupCheck SELECT
freeradius_service_radgroupcheck.id,freeradius_service_radgroupcheck.GroupNa
me,freeradius_service_radgroupcheck.Attribute,freeradius_service_radgroupche
ck.Value,freeradius_service_radgroupcheck.op FROM
freeradius_service_radgroupcheck,freeradius_service_radusergroup WHERE
freeradius_service_radusergroup.Username = ? AND
freeradius_service_radusergroup.GroupName =
freeradius_service_radgroupcheck.GroupName ORDER BY
freeradius_service_radgroupcheck.id
AuthGroupReply SELECT
freeradius_service_radgroupreply.id,freeradius_service_radgroupreply.GroupNa
me,freeradius_service_radgroupreply.Attribute,freeradius_service_radgrouprep
ly.Value,freeradius_service_radgroupreply.op FROM
freeradius_service_radgroupreply,freeradius_service_radusergroup WHERE
freeradius_service_radusergroup.Username = ? AND
freeradius_service_radusergroup.GroupName =
freeradius_service_radgroupreply.GroupName ORDER BY
freeradius_service_radgroupreply.id
AcctStartQuery INSERT into freeradius_service_radacct (AcctSessionId,
AcctUniqueId, UserName, GroupName, Realm, NASIPAddress, NASPort,
NASPortType, AcctStartTime, AcctStopTime,AcctSessionTime, AcctAuthentic,
ConnectInfo_start, ConnectInfo_stop, AcctInputOctets, AcctOutputOctets,
CalledStationId, CallingStationId, AcctTerminateCause, ServiceType,
FramedProtocol, FramedIPAddress, AcctStartDelay, AcctStopDelay,
XAscendSessionSvrKey) VALUES('%{Acct-Session-Id}',
'%{Acct-Unique-Session-Id}', %0, null, '%{Realm}', '%{NAS-IP-Address}',
'%{NAS-Port}', '%{NAS-Port-Type}', '%J', '1900-01-01 00:00:00', '0',
'%{Acct-Authentic}', '%{Connect-Info}', '', '0', '0',
'%{Called-Station-Id}', '', '', '%{Service-Type}', '%{Framed-Protocol}',
'%{Framed-IP-Address}', '%{Acct-Delay-Time}', '0', null)
AcctUpdateQuery UPDATE freeradius_service_radacct SET
FramedIPAddress = '%{Framed-IP-Address}', AcctSessionTime =
'%{Acct-Session-Time}', AcctInputOctets = cast(((0%{Acct-Input-Gigawords} *
4294967296) + %{Acct-Input-Octets}) as numeric(18,0)), AcctOutputOctets =
cast(((0%{Acct-Output-Gigawords} * 4294967296) + %{Acct-Output-Octets}) as
numeric(18,0)) WHERE AcctSessionId = '%{Acct-Session-Id}' AND UserName = %0
AND NASIPAddress= '%{NAS-IP-Address}'
AcctStopQuery UPDATE freeradius_service_radacct SET AcctStopTime = '%J',
AcctSessionTime = '%{Acct-Session-Time}', AcctInputOctets =
cast(((0%{Acct-Input-Gigawords} * 4294967296) + %{Acct-Input-Octets}) as
numeric(18,0)), AcctOutputOctets = cast(((0%{Acct-Output-Gigawords} *
4294967296) + %{Acct-Output-Octets}) as numeric(18,0)), AcctTerminateCause =
'%{Acct-Terminate-Cause}', AcctStopDelay = '%{Acct-Delay-Time}',
Connect
Re: [RADIATOR] Question about TACACS group assignment based on AD groups
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 ne
Re: [RADIATOR] more memory leakage?
On 27.9.2016 18.54, Fredrik Pettai wrote: > Sorry, then I wrote authentication handled, I meant by proxying requests… > > These Radiators are just doing proxying inbetween all our IdP’s in .se > (they are the FLRS's for .SE), and the eduroam ETLR’s (root) servers… Earlier you mentioned you upgraded to 4.16 + patches and this was when you started seeing the process growing. Can you tell which version you used before and what was the 4.16 patchset (ca. which month or so) you first tried. There are all kinds of changes in 4.16 but I'd say not that much that would affect caching incoming and proxied requests. Any versions or timeframe would be useful to better understand what changes were done between the versions. 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
Re: [RADIATOR] more memory leakage?
We've been seeing a leak for about year or more but it's ntlm_auth not radiator itself. We do about 1.8 million auths per day. Our servers have 4 GB RAM and radiator needs to be restarted 3 or 4 times a year. --- Roberto Ullfig - rull...@uic.edu IT Technical Associate Enterprise Architecture and Development | ACCC University of Illinois - Chicago -Original Message----- From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On Behalf Of Fredrik Pettai Sent: Tuesday, September 27, 2016 10:54 AM To: Heikki Vatiainen Cc: radiator@open.com.au Subject: Re: [RADIATOR] more memory leakage? > On 27 Sep 2016, at 11:32, Heikki Vatiainen wrote: > > On 26.9.2016 16.40, Fredrik Pettai wrote: > >> (A rough guestimate of the number of radius authentications handled >> by these servers is ~500.000 Accepts/Rejects per day, RADSEC is >> enabled/running too...) > > If you are using EAP and have not disabled session resumption, can you > try setting EAPTLS_SessionResumptionLimit to a non-default value, for > example 3600 or 7200 (1 hour or 2 hours)? > > This would go to AuthBy(s) where the other EAPTLS_* parameters are. > Now that the limit is no longer smaller of the EAP context timeout and > this value, the default value might be too high for sites that do a > lot of tunnelled EAP and end up caching a lot of sessions. Sorry, then I wrote authentication handled, I meant by proxying requests… These Radiators are just doing proxying inbetween all our IdP’s in .se (they are the FLRS's for .SE), and the eduroam ETLR’s (root) servers… Re, /P ___ 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] more memory leakage?
> On 27 Sep 2016, at 11:32, Heikki Vatiainen wrote: > > On 26.9.2016 16.40, Fredrik Pettai wrote: > >> (A rough guestimate of the number of radius authentications handled >> by these servers is ~500.000 Accepts/Rejects per day, RADSEC is >> enabled/running too...) > > If you are using EAP and have not disabled session resumption, can you > try setting EAPTLS_SessionResumptionLimit to a non-default value, for > example 3600 or 7200 (1 hour or 2 hours)? > > This would go to AuthBy(s) where the other EAPTLS_* parameters are. Now > that the limit is no longer smaller of the EAP context timeout and this > value, the default value might be too high for sites that do a lot of > tunnelled EAP and end up caching a lot of sessions. Sorry, then I wrote authentication handled, I meant by proxying requests… These Radiators are just doing proxying inbetween all our IdP’s in .se (they are the FLRS's for .SE), and the eduroam ETLR’s (root) servers… Re, /P ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] more memory leakage?
> On 26 Sep 2016, at 21:10, Heikki Vatiainen wrote: > > On 26.09.2016 16:40, Fredrik Pettai wrote: > >> I saw that 4.17 was released, and it was plugging at least one memory leak >> according to the Release notes. >> So I’ve upgraded our systems now, but it still looks like Radiator is >> continuing to consume memory at a very fast phase... > > Can you reply to me directly with your configuration (no secrets or > passwords needed)? I'd like to see what you have enabled and what the > parameters are. > > The leak Niels reported happened when radiusd was reloaded to read > configuration changes. Do you do this also? We got a report that there > still seems to be a memory leak wit reload case and we are looking at > this. I'm wondering if this might be related. Or do you see it to grow > even without a reload? No, we do not do regular reload with configuration changes. >> (A rough guestimate of the number of radius authentications handled by these >> servers is ~500.000 Accepts/Rejects per day, RADSEC is enabled/running >> too...) > > Do you have an estimate of unique users? Do most of them use EAP such as > PEAP or EAP-TTLS? I’ll see what I can dig out. From a survey we made earlier, it should be mostly PEAP… Re, /P ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] more memory leakage?
On 26.9.2016 16.40, Fredrik Pettai wrote: > (A rough guestimate of the number of radius authentications handled > by these servers is ~500.000 Accepts/Rejects per day, RADSEC is > enabled/running too...) If you are using EAP and have not disabled session resumption, can you try setting EAPTLS_SessionResumptionLimit to a non-default value, for example 3600 or 7200 (1 hour or 2 hours)? This would go to AuthBy(s) where the other EAPTLS_* parameters are. Now that the limit is no longer smaller of the EAP context timeout and this value, the default value might be too high for sites that do a lot of tunnelled EAP and end up caching a lot of sessions. 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
Re: [RADIATOR] more memory leakage?
On 26.09.2016 16:40, Fredrik Pettai wrote: > I saw that 4.17 was released, and it was plugging at least one memory leak > according to the Release notes. > So I’ve upgraded our systems now, but it still looks like Radiator is > continuing to consume memory at a very fast phase... Can you reply to me directly with your configuration (no secrets or passwords needed)? I'd like to see what you have enabled and what the parameters are. The leak Niels reported happened when radiusd was reloaded to read configuration changes. Do you do this also? We got a report that there still seems to be a memory leak wit reload case and we are looking at this. I'm wondering if this might be related. Or do you see it to grow even without a reload? > (A rough guestimate of the number of radius authentications handled by these > servers is ~500.000 Accepts/Rejects per day, RADSEC is enabled/running too...) Do you have an estimate of unique users? Do most of them use EAP such as PEAP or EAP-TTLS? Thanks, Heikki -- Heikki Vatiainen ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] more memory leakage?
Hi, Since we upgraded OS + Radiator to version 4.16 + patches, we’ve noted that Radiator seemed to leak memory. From having a very small memory footprint, it now consumes 500MB+ of Ram in just a day or two, and keeps on growing... I saw that 4.17 was released, and it was plugging at least one memory leak according to the Release notes. So I’ve upgraded our systems now, but it still looks like Radiator is continuing to consume memory at a very fast phase... Details about the versions of the used components: -bash-4.3$ openssl version OpenSSL 1.0.1t 3 May 2016 -bash-4.3$ perl -v This is perl 5, version 24, subversion 0 (v5.24.0) (I saw that there was a memory leak discovered (and fixed) in perl 5.24.0, but the problem discovered doesn’t seemed to be used in the Radiator code AFAICT, see https://rt.perl.org/Public/Bug/Display.html?id=128680 ) -bash-4.3$ pkg_info |grep ^p5-Net-SSL p5-Net-SSLeay-1.74nb1 Perl5 module for using OpenSSL (A rough guestimate of the number of radius authentications handled by these servers is ~500.000 Accepts/Rejects per day, RADSEC is enabled/running too...) Re, /P ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ServerRADSEC: TLSv1.1 and TLSv1.2 are by default disabled even if all software supports them
On 22.9.2016 11.45, Stefan Winter wrote: > The default that "UseTLS" should trigger is: all TLS versions that are > supported in the system. Agreed. The current UseTLS behaviour is to do what it has done since it was first implemented: enable TLS 1.0. We could, for example, enable all TLS protocols when UseTLS is set and log a message that TLS_Protocols should be used instead for better control of supported versions. Now when some TLS versions are showing their age and TLS 1.3 is upcoming, it's good to have a way to tell what exactly is wanted. > Silently pinning 1.0 is an invitation to continue use of old and weak > crypto protocols. > > Maybe this default could be changed in later versions... Yes, I'll see that this gets attention. -- 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
Re: [RADIATOR] Radius and TACACS+ password obfuscation
On 22.9.2016 12.53, Nadav Hod wrote: > From the looks of things, this requires certain Linux primitives (for > lack of better term) such as rcrypt. This could just be a > misunderstanding. Is there a supported solution for Windows Server > deployments? The example uses rcrypt which is described in Radiator's reference manual, is part of Radiator and is not dependent on the operating system Radiator runs on. It was chosen for the example because it's currently the simplest way to encrypt a secret. There is no reason why other encryption algorithms could not be supported. Also, the encryption key management is not fixed to a single solution, but could utilise, for example, different kinds of vaults in addition to, for example, storing the key somewhere in the OS's file system. By key I mean the encryption key or what ever is required to decrypt the value configured with EncryptedSecret ... 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
Re: [RADIATOR] Radius and TACACS+ password obfuscation
Thanks for the quick reply Heikki, >From the looks of things, this requires certain Linux primitives (for lack of >better term) such as rcrypt. This could just be a misunderstanding. Is there a >supported solution for Windows Server deployments? ____ From: radiator-boun...@open.com.au [radiator-boun...@open.com.au] on behalf of Heikki Vatiainen [h...@open.com.au] Sent: Thursday, September 22, 2016 10:01 AM To: radiator@open.com.au Subject: Re: [RADIATOR] Radius and TACACS+ password obfuscation On 21.9.2016 18.13, Nadav Hod wrote: > I read this in the Radiator 4.17 release notes: > > "Added initial support for encrypting and obfuscating TACACS+ keys in > the configuration file. This is similar to the recently added RADIUS > client shared secret obfuscation. Client and ServerTACACASPLUS now > support EncryptedTACACSPLUSKey and EncryptedKey, respectively. Examples > in the tacacsplusserver.cfg sample configuration file." > > I haven't seen anything regarding radius shared secret obfuscation in > the documentation. Can anyone give a short example of this? See, for example, https://www.open.com.au/radiator/ref/EncryptedSecret_Client.html#EncryptedSecret_Client What's available now is supported for encrypted secrets using a fixed key. What will follow is method to specify the encryption key so that it does not need to be static but can be set, for example, when the process starts up. There are some Radiator users that require that this type of information is not stored in clear text, as we discussed on this list earlier :), and what we now have in Radiator is the foundation for this. To summarise: Using a non-cleartext secret or TACACSC+ key is now possible but managing the encryption keys will be enhanced in the future releases. 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
[RADIATOR] ServerRADSEC: TLSv1.1 and TLSv1.2 are by default disabled even if all software supports them
Hello, I am just now setting up a new incarnation of our RadSEC enabled Radiator server: Radiator 4.17 Net::SSLeay 1.78 OpenSSL 1.0.1e (newest CentOS 7.2 backports) All of which support TLS 1.2. I use a ServerRADSEC clause with UseTLS on but that only establishes TLS 1.0 connections. When poking the server from outside with openssl s_client -tls1_1 or -tls1_2 there is no connection with "SSL3_GET_RECORD:wrong version number". I was able to fix this by adding: TLS_Protocols TLSv1, TLSv1.1, TLSv1.2 and now all is fine on all three version levels. But: it is not exactly a "sane default" to pin all TLS to version 1.0 if newer versions are available on the system. The default that "UseTLS" should trigger is: all TLS versions that are supported in the system. Silently pinning 1.0 is an invitation to continue use of old and weak crypto protocols. Maybe this default could be changed in later versions... Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 0x8A39DC66.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature _______ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radius and TACACS+ password obfuscation
On 21.9.2016 18.13, Nadav Hod wrote: > I read this in the Radiator 4.17 release notes: > > "Added initial support for encrypting and obfuscating TACACS+ keys in > the configuration file. This is similar to the recently added RADIUS > client shared secret obfuscation. Client and ServerTACACASPLUS now > support EncryptedTACACSPLUSKey and EncryptedKey, respectively. Examples > in the tacacsplusserver.cfg sample configuration file." > > I haven't seen anything regarding radius shared secret obfuscation in > the documentation. Can anyone give a short example of this? See, for example, https://www.open.com.au/radiator/ref/EncryptedSecret_Client.html#EncryptedSecret_Client What's available now is supported for encrypted secrets using a fixed key. What will follow is method to specify the encryption key so that it does not need to be static but can be set, for example, when the process starts up. There are some Radiator users that require that this type of information is not stored in clear text, as we discussed on this list earlier :), and what we now have in Radiator is the foundation for this. To summarise: Using a non-cleartext secret or TACACSC+ key is now possible but managing the encryption keys will be enhanced in the future releases. 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
Re: [RADIATOR] What is the "new Radiator load balancer"?
On 21.9.2016 17.37, Nadav Hod wrote: > Looking over the Radiator 4.17 release notes, there is talk of a new > loadbalancer. Any chance someone in the know can elaborate on this > loadbalancer? :) This is the component you can see here: https://www.open.com.au/nfv/ The first image shows traffic arriving via Radius and Diameter load balancers. This is not a generic load balancer but part of distributed Radiator solution, be it NFV, or something that uses Radiator with a load balancer to fan out traffic to Radiator instances. Radiator and its load balancer, which is not a Radiator instance but a specific software that does just load balancing, can communicate with each other and share information. This information is about worker instance health, automatic registration with scale in/out, hints about balancing, for example, to keep EAP streams together. What's currently in Radiator is the first release of Radiator part. The load balancer works currently with NFV only, but will work making it available as a non-NFV package too. 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] Radius and TACACS+ password obfuscation
Hi everyone, I read this in the Radiator 4.17 release notes: "Added initial support for encrypting and obfuscating TACACS+ keys in the configuration file. This is similar to the recently added RADIUS client shared secret obfuscation. Client and ServerTACACASPLUS now support EncryptedTACACSPLUSKey and EncryptedKey, respectively. Examples in the tacacsplusserver.cfg sample configuration file." I haven't seen anything regarding radius shared secret obfuscation in the documentation. Can anyone give a short example of this? ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] What is the "new Radiator load balancer"?
Hi everyone, Looking over the Radiator 4.17 release notes, there is talk of a new loadbalancer. Any chance someone in the know can elaborate on this loadbalancer? :) ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Radiator Version 4.17 released - enhancements, new features, security and other fixes
We are pleased to announce the release of Radiator version 4.17 This version contains enhancements, new features, security and other fixes described below. As usual, the new version is available to current licensees and evaluators from: https://www.open.com.au/radiator/downloads.html 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.17 (2016-09-21) enhancements, new features, security and other fixes Selected compatibility notes, enhancements and fixes radiusd now exits during startup if it can not load the objects required by the configuration file. Hooks and custom code that calls get_plaintext_password or translate_password should be checked for compatibility AuthBy RADSEC now supports Radiator's Gossip framework for reachability information Any hooks or custom code that needs to save data across resumed EAP-TLS, EAP-TTLS or PEAP authentication sessions must now use resume context. See EAP.pm for the details. RADIUS dictionary name space was changed for IANA registered attributes. Any hooks or custom code that accesses RADIUS dictionary, or does RADIUS - Diameter conversion may need updates. JSON time stamp formats were corrected and unified in LogFormat.pm AuthBy DUO now does pre-authentication by default AddressAllocator SQL now supports IPv6 prefix allocation Session resumption for TLS based EAP methods was enhanced Many new features and options for SessionDatabase modules AuthBy RADIUS supports configuration parameter Asynchronous for easier AuthByPolicy handling New MessageLog clauses for logging RADIUS and other messages StatsLog updates including cumulative and derivate statistics HTTP digest authentication must now be enabled per AuthBy basis Security fixes for AuthBy LDAP2 when used with EAP. OSC recommends all AuthBy LDAP2 users to review OSC security advisory OSC-SEC-2016-01 https://www.open.com.au/OSC-SEC-2016-01.html Features not in this release yet, known caveats and other notes OCSP support Selection of proxy algorithms for AuthBy RADSEC No testing with OpenSSL 1.1.0. Testing with OpenSSL 1.0.2h, Net::SSLeay 1.78, IOS 10, Android 7 and Windows 10 PEAP session resumption sometimes fails on Windows. Further investigation is ongoing Major documentation update. Radiator reference manual is available in HTML format again Detailed changes Updated debug log messages for Stream classes. The stream client and server now log the destination name and its currently resolved address more clearly in the debug log messages. This affects log messages for RadSec, Diameter, ServerHTTP and other Stream based modules. AuthBy RADSEC now logs packet dumps for the Status-Server replies it receives from the next hop proxy. The Port configuration variable is now formatted when RadSec Host is activated. This allows logging the actual port number instead of the unformatted configuration value. Added Gossip support for AuthBy RADSEC. The RadSec Hosts can now distribute next hop proxy reachability information with Gossip. The configured Host name, not the current IP address, is used as the key when determining if the current report should be processed. The behaviour is currently slightly different from AuthBy RADIUS. Updated radsec-client.cfg in goodies. Suggested by Jan Tomasek. Updated AuthBy RADSEC log messages to be more clear about destination name, IP address and port. While loading dictionaries, Radiator now logs a warning when the vendor has not been defined for a vendor specific attribute. Correct configuration file names are now logged when there are errors parsing the included configuration files during radiusd startup. Previously the file name might have been the main configuration file name. Reported by Kilian Krause. Clause ends are now checked for matching starts while the configuration file is read. Possible mismatches and incorrectly ended clauses are logged with a warning, but no other action is currently taken. Gossip messages sent by one AuthBy RADIUS module will now be accepted by all the other AuthBy RADIUS modules within the same radiusd instance. Previously the messages were always ignored when they originated from the same instance. This behaviour is now similar to what AuthBy RADSEC does. AuthRADIUS and AuthRADSEC now include the type of the failed request in the Gossip messages. A module using UseStatusServerForFailureDetect will now act only on failed Status-Server requests. With report and help from Paul Dekkers. AuthBy LDAP2 now logs the search filter with the query results Added VENDOR 3GPP 10415 VSA 3GPP-User-Location-Info-Time from document TS 29.061 version 12.10.0 to dictionary. AuthBy DYNADDRESS now uses MapAttribute yiaddr when processing Accounting-Requests. Previously the address was always fetched from Framed-IP-Ad
Re: [RADIATOR] Migrate Cisco CAR MCD database to Radiator
Hi All, Apologies for the delayed response. I decided to use a script to format the userlist data in the Cisco CAR config file for import into MySQL. Thanks much for the feedback. Sample entries below. 322/ Name = 322 Description = "Des: Name PW: password MAC: 94d7.2310.dc12" Password = Enabled = TRUE Group~ = BaseProfile~ = AuthenticationScript~ = AuthorizationScript~ = UserDefined1 = AllowNullPassword = FALSE Attributes/ CheckItems/ Calling-Station-Id = 94d7.2310.dc12 322/ Name = 322 Description = "Des: Customer Name PW password CENT 01 1 05 49 Port 550 MAC 94d7.2310.dc12" Password = Enabled = TRUE Group~ = BaseProfile~ = AuthenticationScript~ = AuthorizationScript~ = UserDefined1 = AllowNullPassword = FALSE Attributes/ Framed-IP-Address = 192.168.1.100 Framed-IP-Netmask = 255.255.255.255 Framed-Route = "192.168.1.100 255.255.255.255" CheckItems/ Calling-Station-Id = 94d7.2310.dc12 Regards, Rohan - Original Message - From: "Sami Keski-Kasari" To: "Rohan Henry" , radiator@open.com.au Sent: Wednesday, August 24, 2016 2:07:42 AM Subject: Re: [RADIATOR] Migrate Cisco CAR MCD database to Radiator Hello Rohan, We have tools to migrate data from Cisco ACS database dumps. If you send us a database dump that includes a couple of tests entries, we can test if our tools works with Cisco CAR too. Best Regards, Sami On 24/08/16 00:07, rohan.henry cwjamaica.com wrote: Hello, Has anyone ever migrated from Cisco CAR radius to Radiator I need to dump userlist tables from Cisco CAR database for migration to Radiator but cannot find any documentation even from Cisco website. Thanks. Rohan _______ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Sami Keski-Kasari Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Windows Client with EAP auth
hi, On 09/14/2016 07:03 AM, Heikki Vatiainen wrote: > >> We use Radiator as radius server, Windows as WiFi client, >> it looks like windows will use system name as radius’s username. >> Can radiator return a message to client to let windows user input their wifi >> login information instead of OS default name? > > One other option might be a separate setup utility that creates the > profile. Please let me know if you are interested in these, I can ask > here about vendors our staff may know. Maybe the eduroam Configuration Assistance Tool (CAT) is worth mentioning. It supports Windows, Apple iOS, Apple OS X, Android & Linux clients. Haven't used it myself, but it's under active development by the eduroam community. https://cat.eduroam.org/ *if* you are an eduroam member. if not, there is the alternative http://802.1x-config.org/ other commercial tools that have wider platform support include XpressConnect and XpressConnect SE from Cloudpath - now Brocade/ruckus, Aruba Clearpass onboarding and SecureW2 however, the initial question is client configuration. the client needs to be configured properly...if not, the initial host/username jun will be rejected...the client may then ask the user to try logging in - a basic OS/client method is pretty much ask user to trust RADIUS server presented (most users just click yes/okay) and then ask for credentials... not too good at all. proper configuration by profile deployment is much better alan _______ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Windows Client with EAP auth
On 09/14/2016 07:03 AM, Heikki Vatiainen wrote: > >> We use Radiator as radius server, Windows as WiFi client, >> it looks like windows will use system name as radius’s username. >> Can radiator return a message to client to let windows user input their wifi >> login information instead of OS default name? > > One other option might be a separate setup utility that creates the > profile. Please let me know if you are interested in these, I can ask > here about vendors our staff may know. Maybe the eduroam Configuration Assistance Tool (CAT) is worth mentioning. It supports Windows, Apple iOS, Apple OS X, Android & Linux clients. Haven't used it myself, but it's under active development by the eduroam community. https://cat.eduroam.org/ Regards, Jeroen van Ingen ICT Service Centre University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands _______ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Windows Client with EAP auth
On 10.9.2016 4.36, Kaiser gentrice wrote: > We use Radiator as radius server, Windows as WiFi client, > it looks like windows will use system name as radius’s username. > Can radiator return a message to client to let windows user input their wifi > login information instead of OS default name? I don't think that is possible. The EAP client picks up a username and that's what is used for the authentication. A solution could be to use, for example, Windows policies to configure the EAP client software to use the desired username. If you don't have centralised management for this, you could search google for something like: windows eduroam peap, and create instructions for your users. What you should watch out for are instructions that, for example, disable RADIUS server certificate checks. Instructions done by many eduroam sites have detailed guides for setting up Windows Wi-Fi authentication. These typically do not skip, but some do, this or any other important steps. One other option might be a separate setup utility that creates the profile. Please let me know if you are interested in these, I can ask here about vendors our staff may know. 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] Windows Client with EAP auth
Dear sir, We use Radiator as radius server, Windows as WiFi client, it looks like windows will use system name as radius’s username. Can radiator return a message to client to let windows user input their wifi login information instead of OS default name? br, kaiser ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Question about TACACS group assignment based on AD groups
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
> 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
[RADIATOR] Question about TACACS group assignment based on AD groups
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
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Reload configuration without restart Radiator RADIUS server
Hello Nadav, It is in our road map, but the schedule is still currently open. Best Regards, Sami On 29/08/16 13:13, Nadav Hod wrote: Hello, Any word regarding non-disruptive configurations? *From:* Nadav Hod *Sent:* Sunday, August 07, 2016 7:16 PM *To:* Sami Keski-Kasari; radiator@open.com.au *Subject:* RE: [RADIATOR] Reload configuration without restart Radiator RADIUS server Hi Sami, Are non-disruptive configurations on the roadmap for the end of the year? Heikki wrote in a post from June 10th that he'll ask others to publish more information regarding the Radiator roadmap, although I haven't seen any such publications thus far. ---- *From:* radiator-boun...@open.com.au [radiator-boun...@open.com.au] on behalf of Sami Keski-Kasari [sam...@open.com.au] *Sent:* Tuesday, July 26, 2016 2:23 PM *To:* radiator@open.com.au *Subject:* Re: [RADIATOR] Reload configuration without restart Radiator RADIUS server Hello, Currently configuration file is read only when reloading or restarting the process. It is possible to do some changes to Radiator configuration on the fly via Monitor port. Please see more at section 5.102 in https://www.open.com.au/radiator/ref.pdf We are going to extend support for on the fly configuration changes in the near future. Best Regards, Sami On 19/07/16 07:49, Vicente Ortega Torres wrote: Hello, Is it possible to reload the Radiator configuration (which is taken from /etc/radiator/ radius.cfg) without restart the server or signaling SIGHUP? We are interested in reload the configuration of Handlers and AuthBys. Thanks in advance ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Sami Keski-Kasari 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. -- Sami Keski-Kasari Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Reload configuration without restart Radiator RADIUS server
Hello, Any word regarding non-disruptive configurations? From: Nadav Hod Sent: Sunday, August 07, 2016 7:16 PM To: Sami Keski-Kasari; radiator@open.com.au Subject: RE: [RADIATOR] Reload configuration without restart Radiator RADIUS server Hi Sami, Are non-disruptive configurations on the roadmap for the end of the year? Heikki wrote in a post from June 10th that he'll ask others to publish more information regarding the Radiator roadmap, although I haven't seen any such publications thus far. ____ From: radiator-boun...@open.com.au [radiator-boun...@open.com.au] on behalf of Sami Keski-Kasari [sam...@open.com.au] Sent: Tuesday, July 26, 2016 2:23 PM To: radiator@open.com.au Subject: Re: [RADIATOR] Reload configuration without restart Radiator RADIUS server Hello, Currently configuration file is read only when reloading or restarting the process. It is possible to do some changes to Radiator configuration on the fly via Monitor port. Please see more at section 5.102 in https://www.open.com.au/radiator/ref.pdf We are going to extend support for on the fly configuration changes in the near future. Best Regards, Sami On 19/07/16 07:49, Vicente Ortega Torres wrote: Hello, Is it possible to reload the Radiator configuration (which is taken from /etc/radiator/ radius.cfg) without restart the server or signaling SIGHUP? We are interested in reload the configuration of Handlers and AuthBys. Thanks in advance ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Sami Keski-Kasari Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Migrate Cisco CAR MCD database to Radiator
Hello Rohan, We have tools to migrate data from Cisco ACS database dumps. If you send us a database dump that includes a couple of tests entries, we can test if our tools works with Cisco CAR too. Best Regards, Sami On 24/08/16 00:07, rohan.henry cwjamaica.com wrote: Hello, Has anyone ever migrated from Cisco CAR radius to Radiator I need to dump userlist tables from Cisco CAR database for migration to Radiator but cannot find any documentation even from Cisco website. Thanks. Rohan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Sami Keski-Kasari Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Migrate Cisco CAR MCD database to Radiator
Hello Rohan - Yes I am fairly sure we know how to do this. I’ll let someone from the office confirm - I think its a pay-for service. regards Hugh > On 24 Aug 2016, at 07:07, rohan.henry cwjamaica.com > wrote: > > Hello, > > Has anyone ever migrated from Cisco CAR radius to Radiator > > I need to dump userlist tables from Cisco CAR database for migration to > Radiator but cannot find any documentation even from Cisco website. > > Thanks. > > Rohan > ___ > 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] Migrate Cisco CAR MCD database to Radiator
Hello, Has anyone ever migrated from Cisco CAR radius to Radiator I need to dump userlist tables from Cisco CAR database for migration to Radiator but cannot find any documentation even from Cisco website. Thanks. Rohan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Reload configuration without restart Radiator RADIUS server
Hi Sami, Are non-disruptive configurations on the roadmap for the end of the year? Heikki wrote in a post from June 10th that he'll ask others to publish more information regarding the Radiator roadmap, although I haven't seen any such publications thus far. ____ From: radiator-boun...@open.com.au [radiator-boun...@open.com.au] on behalf of Sami Keski-Kasari [sam...@open.com.au] Sent: Tuesday, July 26, 2016 2:23 PM To: radiator@open.com.au Subject: Re: [RADIATOR] Reload configuration without restart Radiator RADIUS server Hello, Currently configuration file is read only when reloading or restarting the process. It is possible to do some changes to Radiator configuration on the fly via Monitor port. Please see more at section 5.102 in https://www.open.com.au/radiator/ref.pdf We are going to extend support for on the fly configuration changes in the near future. Best Regards, Sami On 19/07/16 07:49, Vicente Ortega Torres wrote: Hello, Is it possible to reload the Radiator configuration (which is taken from /etc/radiator/ radius.cfg) without restart the server or signaling SIGHUP? We are interested in reload the configuration of Handlers and AuthBys. Thanks in advance ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Sami Keski-Kasari Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and Load Balancer
This may be the case now, but pretty sure we went down this road YEARS ago and even with BindAddress, packets were still being sourced from the main IP address. In the mailing list archives this argument may exist. I vaguely remember being told by Hugh that it was not possible in Perl at the time to choose the source address to respond from. Again, not arguing that now; just saying what we ran into in the past. -- Robert inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu > On Jul 29, 2016, at 6:17 AM, Heikki Vatiainen wrote: > > When BindAddress is configured, a socket is created and bound for each > address defined by BindAddress. In this case the source address of a > reply is the specific non-wildcard address the socket was bound to. > > In short: BindAddress can be useful on multi homed hosts. However, if IP > addresses are added and removed dynamically, this can cause problems > because the addresses are now part of the Radiator configuration too. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and Load Balancer
In my experience this is not the case. It will LISTEN on those addresses for sure. But it’s return packets are always sourced from the primary IP address of the outgoing interface. DSR will work, but the clients will receive a response from an IP address that is not of the configure RADIUS server. This may (but should not) work for various clients. This may of changed, in recent years. YMMV. -- Robert inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu > On Jul 29, 2016, at 5:19 AM, Hartmaier Alexander > wrote: > > 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. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and Load Balancer
On 27.07.2016 21:32, Robert Blayzor wrote: > 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). Yes, this happens by default when BindAddress is not configured. The default is to bind the RADIUS listen ports with the wildcard address 0.0.0.0. When the replies are sent, they are from the socket that received the request. When the socket has been bound with the wildcard address, kernel will pick a source address for the reply. When BindAddress is configured, a socket is created and bound for each address defined by BindAddress. In this case the source address of a reply is the specific non-wildcard address the socket was bound to. In short: BindAddress can be useful on multi homed hosts. However, if IP addresses are added and removed dynamically, this can cause problems because the addresses are now part of the Radiator configuration too. > Most clients will probably ignore the response as it’s > coming from a different address. Yes, they will probably log the replies as unknown messages or something similar. > With Radiator being Perl, I don’t think you can force Radiator to > answer from a specific source address on the server. With wildcard bind address things can get complicated. There are socket functions that allow querying the address the request was sent to, but these are OS specific and may require additional modules for accessing, for example sendmsg() and other functions. The easiest way to handle problems with reply addresses on multi homed hosts is to use BindAddress, if possible. Thanks, Heikki -- Heikki Vatiainen Open System Consultants ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and Load Balancer
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] Radiator and Load Balancer
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 ... -- no name ... no slogan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and Load Balancer
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. NAT will work via the F5, you just have to make sure that the response traffic goes back out to the load balancer it came in on. -- Robert inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu > On Jul 27, 2016, at 1:38 PM, shaun gibson wrote: > > i've used direct server return for radius and it seemed to work well : > > http://blog.haproxy.com/2011/07/29/layer-4-load-balancing-direct-server-return-mode/ > https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return > > using the f5 for inbound and outbound traffic nat will also work, just > depends what your requirements are ... ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and Load Balancer
Thanks Shaun. This is good reading. Barry On Wed, Jul 27, 2016 at 11:38 AM, shaun gibson wrote: > On 27/07/2016 18:14, Barry Ard wrote: > > > We are running into some challenges configuring a new environment for > > Eduroam. > > > > Recently we have moved away from 2 servers running multiple radiator > > processes to a multiple VMs behind an F5 load balancer. This has been > > working well for our wireless infrastructure but has been posing > > challenges as we are trying to include our Eduroam config. > > > > The F5 is NATing to the VMs. The VMs have 2 interfaces: eth0 is a > > private address facing the F5, eth1 is a public address and is the > > default gateway. > > > > I have created a test enviroment with an external radius server to > > simulate Eduroam. > > Initially proxied requests would transit the VMs default gateway which > > I think is undesriable so I created a static route for the external > > radius server to force it out the load balancer facing interface. Now > > proxied requests have a private address which of course will not work. > > > > I think the desirable scenario would be for proxied requests to exit > > through the F5 and be NAT’d to source from the F5 external address. My > > colleague who admins the load balancer is hesitant to NAT externally > > using an address that is currently listening on a service. He thinks > > this is getting too complicated. > > > > I am sure others are using a load balancer in this scenario so please > > tell me what you are doing. > > > i've used direct server return for radius and it seemed to work well : > > > http://blog.haproxy.com/2011/07/29/layer-4-load-balancing-direct-server-return-mode/ > > https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return > > using the f5 for inbound and outbound traffic nat will also work, just > depends what your requirements are ... > > > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator > -- Barry Ard barry@ualberta.ca IST University of Alberta Edmonton, Alberta Canada ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and Load Balancer
On 27/07/2016 18:14, Barry Ard wrote: > We are running into some challenges configuring a new environment for > Eduroam. > > Recently we have moved away from 2 servers running multiple radiator > processes to a multiple VMs behind an F5 load balancer. This has been > working well for our wireless infrastructure but has been posing > challenges as we are trying to include our Eduroam config. > > The F5 is NATing to the VMs. The VMs have 2 interfaces: eth0 is a > private address facing the F5, eth1 is a public address and is the > default gateway. > > I have created a test enviroment with an external radius server to > simulate Eduroam. > Initially proxied requests would transit the VMs default gateway which > I think is undesriable so I created a static route for the external > radius server to force it out the load balancer facing interface. Now > proxied requests have a private address which of course will not work. > > I think the desirable scenario would be for proxied requests to exit > through the F5 and be NAT’d to source from the F5 external address. My > colleague who admins the load balancer is hesitant to NAT externally > using an address that is currently listening on a service. He thinks > this is getting too complicated. > > I am sure others are using a load balancer in this scenario so please > tell me what you are doing. > i've used direct server return for radius and it seemed to work well : http://blog.haproxy.com/2011/07/29/layer-4-load-balancing-direct-server-return-mode/ https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return using the f5 for inbound and outbound traffic nat will also work, just depends what your requirements are ... signature.asc Description: OpenPGP digital signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Radiator and Load Balancer
We are running into some challenges configuring a new environment for Eduroam. Recently we have moved away from 2 servers running multiple radiator processes to a multiple VMs behind an F5 load balancer. This has been working well for our wireless infrastructure but has been posing challenges as we are trying to include our Eduroam config. The F5 is NATing to the VMs. The VMs have 2 interfaces: eth0 is a private address facing the F5, eth1 is a public address and is the default gateway. I have created a test enviroment with an external radius server to simulate Eduroam. Initially proxied requests would transit the VMs default gateway which I think is undesriable so I created a static route for the external radius server to force it out the load balancer facing interface. Now proxied requests have a private address which of course will not work. I think the desirable scenario would be for proxied requests to exit through the F5 and be NAT’d to source from the F5 external address. My colleague who admins the load balancer is hesitant to NAT externally using an address that is currently listening on a service. He thinks this is getting too complicated. I am sure others are using a load balancer in this scenario so please tell me what you are doing. Thanks, Barry -- Barry Ard barry@ualberta.ca IST University of Alberta Edmonton, Alberta Canada ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Reload configuration without restart Radiator RADIUS server
Hello, Currently configuration file is read only when reloading or restarting the process. It is possible to do some changes to Radiator configuration on the fly via Monitor port. Please see more at section 5.102 in https://www.open.com.au/radiator/ref.pdf We are going to extend support for on the fly configuration changes in the near future. Best Regards, Sami On 19/07/16 07:49, Vicente Ortega Torres wrote: Hello, Is it possible to reload the Radiator configuration (which is taken from /etc/radiator/ radius.cfg) without restart the server or signaling SIGHUP? We are interested in reload the configuration of Handlers and AuthBys. Thanks in advance ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Sami Keski-Kasari 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] Reload configuration without restart Radiator RADIUS server
Hello, Is it possible to reload the Radiator configuration (which is taken from /etc/radiator/ radius.cfg) without restart the server or signaling SIGHUP? We are interested in reload the configuration of Handlers and AuthBys. Thanks in advance ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Duplicate packets
Hello Mahmoud - Alan is correct, you at least need to acknowledge the requests, else you will get retries. Check the RADIUS RFC’s for a description of how the RADIUS protocol is designed. You will find the RFC’s in the “doc” directory of the Radiator distribution, as well as online. BTW - your configuration file is no longer available on Pastebin. regards Hugh > On 18 Jul 2016, at 20:34, Mahmoud Abdelsalam wrote: > > Hi Alan, > > Thanks for your reply, it works without duplicates for almost 97% of the > accounts, could you please point me to documentation of this. > > Regards, > > Mahmoud Abdelsalam. > > > > On 07/18/16 12:25, a.l.m.bu...@lboro.ac.uk wrote: >> Hi, >> >>> I am not handling start packets so they are ignored, as you may noticed >> at least acknowledge them. if you dont handle them and ignore them then any >> decent NAS will resend >> them and/or mark your server as down/dead :( >> >> alan > -- Hugh Irvine h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER, SIM, etc. Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Duplicate packets
Hi Alan, Thanks for your reply, it works without duplicates for almost 97% of the accounts, could you please point me to documentation of this. Regards, Mahmoud Abdelsalam. On 07/18/16 12:25, a.l.m.bu...@lboro.ac.uk wrote: > Hi, > >> I am not handling start packets so they are ignored, as you may noticed > at least acknowledge them. if you dont handle them and ignore them then any > decent NAS will resend > them and/or mark your server as down/dead :( > > alan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Duplicate packets
Hi, > I am not handling start packets so they are ignored, as you may noticed at least acknowledge them. if you dont handle them and ignore them then any decent NAS will resend them and/or mark your server as down/dead :( alan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Duplicate packets
Hello Hugh, As the term-cause is user-request, I identified the issue as faulty PPPoE client(i.e customer terminal router) because the issue is not general for all, i mean it happens with only some accounts. Please advise. Best Regards, Mahmoud Abdelsalam. On 07/18/16 11:11, Mahmoud Abdelsalam wrote: > Hello Hugh, > > I am not handling start packets so they are ignored, as you may > noticed in the debug, with some of them it receives duplicates with > the same session ID while with some others it receives two-way > duplicates, I mean it receives parent and child sessions at the same > time and then duplicates for both, the child session has this > cisco-avpair = "parent-session-id=id". > > Also I handle stop packets, here is a DB dump: > > http://pastebin.com/J8WQFCAf > > and here is my config: > > http://pastebin.com/xMiuQGHH > > Best Regards, > > Mahmoud Abdelsalam. > > On 07/18/16 09:38, Hugh Irvine wrote: >> Hello Mahmoud - >> >> The origin of all RADIUS requests is your network equipment. >> >> The only way duplicates happen is if the RADIUS server does not >> respond within the RADIUS timeout period or if the response does not >> arrive at the originiating device. >> >> In this particular case however, the Radiator debug log shows that >> the Radiator configuration file does not properly handle these >> accounting requests, so they are ignored. >> >> I would need to see a copy of your Radiator configuration file to be >> able to say any more. >> >> regards >> >> Hugh >> >> >>> On 18 Jul 2016, at 16:12, Mahmoud Abdelsalam >>> wrote: >>> >>> Hello, >>> >>> I have a weird situation here where our network team suspects Radiator >>> as the cause, I am getting duplicate packets(Start,Stop) on Radiator, >>> here is a sample: >>> >>> http://pastebin.com/M3D5P9wK >>> >>> We use both Cisco ISG and Mikrotik for PPPoE. >>> >>> I know Radiator is working fine and it has been for more than two years >>> but I need an advice, could radiator at any case be the cause of such a >>> duplicating? >>> >>> Please advice. >>> >>> Best Regards, >>> >>> Mahmoud Abdelsalam. >>> >>> >>> ___ >>> radiator mailing list >>> radiator@open.com.au >>> http://www.open.com.au/mailman/listinfo/radiator >> >> -- >> >> Hugh Irvine >> h...@open.com.au >> >> Radiator: the most portable, flexible and configurable RADIUS server >> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, >> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, >> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, >> DIAMETER, SIM, etc. >> Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc. >> > ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Duplicate packets
Hello Hugh, I am not handling start packets so they are ignored, as you may noticed in the debug, with some of them it receives duplicates with the same session ID while with some others it receives two-way duplicates, I mean it receives parent and child sessions at the same time and then duplicates for both, the child session has this cisco-avpair = "parent-session-id=id". Also I handle stop packets, here is a DB dump: http://pastebin.com/J8WQFCAf and here is my config: http://pastebin.com/xMiuQGHH Best Regards, Mahmoud Abdelsalam. On 07/18/16 09:38, Hugh Irvine wrote: > Hello Mahmoud - > > The origin of all RADIUS requests is your network equipment. > > The only way duplicates happen is if the RADIUS server does not respond > within the RADIUS timeout period or if the response does not arrive at the > originiating device. > > In this particular case however, the Radiator debug log shows that the > Radiator configuration file does not properly handle these accounting > requests, so they are ignored. > > I would need to see a copy of your Radiator configuration file to be able to > say any more. > > regards > > Hugh > > >> On 18 Jul 2016, at 16:12, Mahmoud Abdelsalam >> wrote: >> >> Hello, >> >> I have a weird situation here where our network team suspects Radiator >> as the cause, I am getting duplicate packets(Start,Stop) on Radiator, >> here is a sample: >> >> http://pastebin.com/M3D5P9wK >> >> We use both Cisco ISG and Mikrotik for PPPoE. >> >> I know Radiator is working fine and it has been for more than two years >> but I need an advice, could radiator at any case be the cause of such a >> duplicating? >> >> Please advice. >> >> Best Regards, >> >> Mahmoud Abdelsalam. >> >> >> ___ >> radiator mailing list >> radiator@open.com.au >> http://www.open.com.au/mailman/listinfo/radiator > > -- > > Hugh Irvine > h...@open.com.au > > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, > TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, > DIAMETER, SIM, etc. > Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc. > ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Duplicate packets
Hello Mahmoud - The origin of all RADIUS requests is your network equipment. The only way duplicates happen is if the RADIUS server does not respond within the RADIUS timeout period or if the response does not arrive at the originiating device. In this particular case however, the Radiator debug log shows that the Radiator configuration file does not properly handle these accounting requests, so they are ignored. I would need to see a copy of your Radiator configuration file to be able to say any more. regards Hugh > On 18 Jul 2016, at 16:12, Mahmoud Abdelsalam wrote: > > Hello, > > I have a weird situation here where our network team suspects Radiator > as the cause, I am getting duplicate packets(Start,Stop) on Radiator, > here is a sample: > > http://pastebin.com/M3D5P9wK > > We use both Cisco ISG and Mikrotik for PPPoE. > > I know Radiator is working fine and it has been for more than two years > but I need an advice, could radiator at any case be the cause of such a > duplicating? > > Please advice. > > Best Regards, > > Mahmoud Abdelsalam. > > > ___ > 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] Duplicate packets
Hello, I have a weird situation here where our network team suspects Radiator as the cause, I am getting duplicate packets(Start,Stop) on Radiator, here is a sample: http://pastebin.com/M3D5P9wK We use both Cisco ISG and Mikrotik for PPPoE. I know Radiator is working fine and it has been for more than two years but I need an advice, could radiator at any case be the cause of such a duplicating? Please advice. Best Regards, Mahmoud Abdelsalam. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Questions regarding new release and current roadmap
On 6.7.2016 13.26, Hartmaier Alexander wrote: >> 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. > 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. This is in the current 4.16 patches which means it will be part of the next release but it is still work in progress. In patches, see the entry for 2016-02-29. 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
Re: [RADIATOR] Multiple AuthBy inside an Handler
Hi Marco- Take a look at AuthByPolicy in section 5.27.1 of the manual. The default behavior is- • ContinueWhileIgnore This is the default. Continue trying to authenticate until either Accept, Challenge or Reject Because the first AuthBy is handling Start messages it satisfies the handler and the second AuthBy is not called. You could set AuthByPolicy ContinueAlways in the Handler to always execute all of the AuthBy clauses. [cid:A5561F0C-29ED-4FB5-B132-7DDD0D907642] Frank Danielson | Chief Technology Officer • fdaniel...@csky.com On Jul 6, 2016, at 6:45 AM, Marco Marino mailto:marino@gmail.com>> wrote: Hi, I'm trying to adjust a configuration problem on an old server that uses radiator. Actually I have: AuthBy auth1 AuthBy auth2 SessionDatabase SDBpppoe_start Identifier auth1 AccountingStartsOnly DBSourcedbi:mysql:radius:X.Y.Z.W DBUsername radius DBAuth DBSourcedbi:mysql:radius:X.Y.Z.K DBUsername radius DBAuth yyy AuthSelect AcctSQLStatement update SUBSCRIBERS_PPPOE set AUTHCOUNTER=AUTHCOUNTER+1 where USERNAME='%n' Identifier auth2 DBSourcedbi:mysql:radius:a.b.c.d <- Different db respect to auth1!! DBUsername radius DBAuth x AccountingTable ACCOUNTING DateFormat %Y-%m-%d %T AcctColumnDef USERNAME,User-Name AcctColumnDef TIME_STAMP,Timestamp,integer-date AcctColumnDef ACCTSTATUSTYPE,Acct-Status-Type AcctColumnDef ACCTDELAYTIME,Acct-Delay-Time,integer AcctColumnDef ACCTINPUTOCTETS,Acct-Input-Octets,integer AcctColumnDef ACCTOUTPUTOCTETS,Acct-Output-Octets,integer AcctColumnDef ACCTSESSIONID,Acct-Session-Id AcctColumnDef ACCTSESSIONTIME,Acct-Session-Time,integer AcctColumnDef ACCTTERMINATECAUSE,Acct-Terminate-Cause, AcctColumnDef NASIDENTIFIER,NAS-Identifier AcctColumnDef NASPORT,NAS-Port,integer AcctColumnDef FRAMEDIPADDRESS,Framed-IP-Address, char HandleAcctStatusTypes Start,Stop,Alive Actually auth2 Doesn't write Start request in the Db. It works only for Stop and Alive. Please, someone can help me? Thank you _______ radiator mailing list radiator@open.com.au<mailto: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
[RADIATOR] Multiple AuthBy inside an Handler
Hi, I'm trying to adjust a configuration problem on an old server that uses radiator. Actually I have: AuthBy auth1 AuthBy auth2 SessionDatabase SDBpppoe_start Identifier auth1 AccountingStartsOnly DBSourcedbi:mysql:radius:X.Y.Z.W DBUsername radius DBAuth DBSourcedbi:mysql:radius:X.Y.Z.K DBUsername radius DBAuth yyy AuthSelect AcctSQLStatement update SUBSCRIBERS_PPPOE set AUTHCOUNTER=AUTHCOUNTER+1 where USERNAME='%n' Identifier auth2 DBSourcedbi:mysql:radius:a.b.c.d <- Different db respect to auth1!! DBUsername radius DBAuth x AccountingTable ACCOUNTING DateFormat %Y-%m-%d %T AcctColumnDef USERNAME,User-Name AcctColumnDef TIME_STAMP,Timestamp,integer-date AcctColumnDef ACCTSTATUSTYPE,Acct-Status-Type AcctColumnDef ACCTDELAYTIME,Acct-Delay-Time,integer AcctColumnDef ACCTINPUTOCTETS,Acct-Input-Octets,integer AcctColumnDef ACCTOUTPUTOCTETS,Acct-Output-Octets,integer AcctColumnDef ACCTSESSIONID,Acct-Session-Id AcctColumnDef ACCTSESSIONTIME,Acct-Session-Time,integer AcctColumnDef ACCTTERMINATECAUSE,Acct-Terminate-Cause, AcctColumnDef NASIDENTIFIER,NAS-Identifier AcctColumnDef NASPORT,NAS-Port,integer AcctColumnDef FRAMEDIPADDRESS,Framed-IP-Address, char HandleAcctStatusTypes Start,Stop,Alive Actually auth2 Doesn't write Start request in the Db. It works only for Stop and Alive. Please, someone can help me? Thank you ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Questions regarding new release and current roadmap
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] Questions regarding new release and current roadmap
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. Thanks for your input, 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
Re: [RADIATOR] OTP Authentication failed logging
On 24.6.2016 13.50, Hartmaier Alexander wrote: > Will you change the log message? This is now changed in the current patches. >> 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. If there will be need for customisation, $self is passed to the hook so it's possible to call $self->log() to log what is required for failed OTPs. Thanks again for reporting this, 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
Re: [RADIATOR] ServerTACACSPLUS logging improvements
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
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
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<mailto: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] Conditional Authby's
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
Re: [RADIATOR] Questions regarding new release and current roadmap
Hi Nadav,
I had similar needs some years ago with radiator (basically, use the
site's instance of an authentication backend (when I remember corrently,
it's been a distibuted LDAP those days)). The very old style solution
(please don't crucify me ;-) ) was basically the use of M4 macros.
So radius.conf was generated by m4, which used site-specific include
files to fill the 'local settings' into the correct places (and much
more.. so the radius.m4 was quite static, relativly easy to understand
and manage while the compliled version was 'long long')
just my 2ct's
regards
Martin
>
> You're assuming that whoever owns Radiator servers has a team who operate
> these complex CM systems, and are interested in taking responsibility for
> their configuration. That's not the case.
>
> I'm interested in a very humble feature that shouldn't require such systems
> nor much complexity: being able to import variables from external files/DB.
> These can be stored in memory when the Radiator process is loaded.
>
> It would definitely go a long way to allowing an organization to create a
> generic Radiator installation, having to change a minimal number of variables
> that are server and site specific.
>
>
> From: radiator-boun...@open.com.au [radiator-boun...@open.com.au] on behalf
> of shaun gibson [xcor...@gmail.com]
> Sent: Wednesday, June 29, 2016 3:38 PM
> To: radiator@open.com.au
> Subject: Re: [RADIATOR] Questions regarding new release and current roadmap
>
> On 29/06/2016 13:23, Nadav Hod wrote:
>
>>
>>
>> 2.5) I probably wasn't clear enough. The include command isn't what I'm
>> looking for since that takes blocks of configuration, not variables, and
>> embeds it in the current configuration. It can't be used to extract a
>> specific variable within that external file. A header file isn't a
>> configuration file which is put into another configuration file, it's just
>> variables and declarations.
>>
>> I've used Radiator 4.15, and I couldn't use external variables as part of
>> parameters in order to make a generic configuration. What I'm looking for is
>> something like the following: assume I have an AuthBy LDAP2 clause. I would
>> like to declare:
>>
>> Host %{GlobalVar:my_ldap_variables.txt::FirstHost}
>>
>> In this example my_ldap_variables.txt contains variables bindings for LDAP
>> configurations, FirstHost being one of them.
>>
>> Something like this, as far as I can tell, isn't possible today. I would
>> need to have FirstHost configured within the local configuration file.
>>
>> If I could create a directory on each server that contains files, each of
>> which contain variables relevant to that file, it would make things very
>> easy and manageable. I could put the same Radiator configuration on each
>> server, and just update the variables per server.
>>
>> Is this possible with Radiator using existing features?
>>
>
> hi nadav
>
> there is no need for radiator to do any of the above as there are
> numerous tools/suites for exactly this sort of thing : saltstack,
> puppet, ansible, chef et al
>
>
>
>
> ___
> 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] Questions regarding new release and current roadmap
Hi,
You're assuming that whoever owns Radiator servers has a team who operate these
complex CM systems, and are interested in taking responsibility for their
configuration. That's not the case.
I'm interested in a very humble feature that shouldn't require such systems nor
much complexity: being able to import variables from external files/DB. These
can be stored in memory when the Radiator process is loaded.
It would definitely go a long way to allowing an organization to create a
generic Radiator installation, having to change a minimal number of variables
that are server and site specific.
____
From: radiator-boun...@open.com.au [radiator-boun...@open.com.au] on behalf of
shaun gibson [xcor...@gmail.com]
Sent: Wednesday, June 29, 2016 3:38 PM
To: radiator@open.com.au
Subject: Re: [RADIATOR] Questions regarding new release and current roadmap
On 29/06/2016 13:23, Nadav Hod wrote:
>
>
> 2.5) I probably wasn't clear enough. The include command isn't what I'm
> looking for since that takes blocks of configuration, not variables, and
> embeds it in the current configuration. It can't be used to extract a
> specific variable within that external file. A header file isn't a
> configuration file which is put into another configuration file, it's just
> variables and declarations.
>
> I've used Radiator 4.15, and I couldn't use external variables as part of
> parameters in order to make a generic configuration. What I'm looking for is
> something like the following: assume I have an AuthBy LDAP2 clause. I would
> like to declare:
>
> Host %{GlobalVar:my_ldap_variables.txt::FirstHost}
>
> In this example my_ldap_variables.txt contains variables bindings for LDAP
> configurations, FirstHost being one of them.
>
> Something like this, as far as I can tell, isn't possible today. I would need
> to have FirstHost configured within the local configuration file.
>
> If I could create a directory on each server that contains files, each of
> which contain variables relevant to that file, it would make things very easy
> and manageable. I could put the same Radiator configuration on each server,
> and just update the variables per server.
>
> Is this possible with Radiator using existing features?
>
hi nadav
there is no need for radiator to do any of the above as there are
numerous tools/suites for exactly this sort of thing : saltstack,
puppet, ansible, chef et al
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Is the Radiator NFV customizable?
> On 29 Jun 2016, at 11:32, Nadav Hod wrote: > > Any chance OSC will be creating a video for NFV installation on > OpenStack/ESXi in the near future? > the video would be quite boring actually as there is very few visual things to see :) Instantiating a new Radiator NFV stack on OpenStack takes approximately 20 minutes: - OpenStack Heat orchestration creates automatically those 11 VMs and other OpenStack related resources as e.g. network and auto scaling group based on Heat orchestration template. - Chef recipes are used to install and configure software components on VMs based on nodes' role. There’s however an ad video available at http://www.open.com.au/nfv/ ;) BR -- Tuure Vartiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Questions regarding new release and current roadmap
On 29/06/2016 13:23, Nadav Hod wrote:
>
>
> 2.5) I probably wasn't clear enough. The include command isn't what I'm
> looking for since that takes blocks of configuration, not variables, and
> embeds it in the current configuration. It can't be used to extract a
> specific variable within that external file. A header file isn't a
> configuration file which is put into another configuration file, it's just
> variables and declarations.
>
> I've used Radiator 4.15, and I couldn't use external variables as part of
> parameters in order to make a generic configuration. What I'm looking for is
> something like the following: assume I have an AuthBy LDAP2 clause. I would
> like to declare:
>
> Host %{GlobalVar:my_ldap_variables.txt::FirstHost}
>
> In this example my_ldap_variables.txt contains variables bindings for LDAP
> configurations, FirstHost being one of them.
>
> Something like this, as far as I can tell, isn't possible today. I would need
> to have FirstHost configured within the local configuration file.
>
> If I could create a directory on each server that contains files, each of
> which contain variables relevant to that file, it would make things very easy
> and manageable. I could put the same Radiator configuration on each server,
> and just update the variables per server.
>
> Is this possible with Radiator using existing features?
>
hi nadav
there is no need for radiator to do any of the above as there are
numerous tools/suites for exactly this sort of thing : saltstack,
puppet, ansible, chef et al
signature.asc
Description: OpenPGP digital signature
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Questions regarding new release and current roadmap
Hi Alan,
2.5) I probably wasn't clear enough. The include command isn't what I'm looking
for since that takes blocks of configuration, not variables, and embeds it in
the current configuration. It can't be used to extract a specific variable
within that external file. A header file isn't a configuration file which is
put into another configuration file, it's just variables and declarations.
I've used Radiator 4.15, and I couldn't use external variables as part of
parameters in order to make a generic configuration. What I'm looking for is
something like the following: assume I have an AuthBy LDAP2 clause. I would
like to declare:
Host %{GlobalVar:my_ldap_variables.txt::FirstHost}
In this example my_ldap_variables.txt contains variables bindings for LDAP
configurations, FirstHost being one of them.
Something like this, as far as I can tell, isn't possible today. I would need
to have FirstHost configured within the local configuration file.
If I could create a directory on each server that contains files, each of which
contain variables relevant to that file, it would make things very easy and
manageable. I could put the same Radiator configuration on each server, and
just update the variables per server.
Is this possible with Radiator using existing features?
2.6) Password vaults are designed to not only maintain passwords (by a strong
complexity policy, frequent generation of new passwords, etc.) but also be
physically tamper-proof, provide high availability and be FIPS 140-2 compliant.
That's not the same as storing it on a mysql database on a remote machine.
The service running Radiator can be a strong user which needs to know only the
hostname of the clients, without the passwords. The passwords can be maintained
somewhere else. Yes, passwords will be loaded into RAM during authentication
and a more sophisticated attacker can extract these passwords locally if they
are local admins, but password vaults update these passwords frequently so that
it doesn't really matter.
I think that allowing a 3rd party solution manage the passwords, assuming that
the API exists, could help secure credentials immensely.
From: a.l.m.bu...@lboro.ac.uk [a.l.m.bu...@lboro.ac.uk]
Sent: Wednesday, June 29, 2016 1:09 PM
To: Nadav Hod
Cc: Heikki Vatiainen; radiator@open.com.au
Subject: Re: [RADIATOR] Questions regarding new release and current roadmap
Hi,
> 2.5) A method of synchronizing configuration files (apart from certain
> variables) across multiple servers. If all Radiator servers have very similar
> configuration and are distributed for load balancing and redundancy, it's a
> shame that the configuration needs to be managed and configured separately
> for each server. There are differences between servers, but the bulk of the
> configuration can remain the same.
>
> There is 3rd party software such as rsync for synchronizing files, but the
> variables for each Radiator configuration file have to be within the file
> itself (as far as I can tell). If the variables could be configured outside
> of each configuration file, such as a header file, this would allow for
> synchronizing the configuration files effectively across all servers while
> still taking into account the differences between each server.
eh??? we do multi server configuration syncing already - you know that you
can just include different files for
each server...using...a headerfile as you say - our radius.cfg contains all
local requirements and then pulls in
the local config file for the server. (in our case we use a database to hold
all details, generate the required
new configs for each server then push out to each server)
> 2.6) A more secure method for storing credentials, at the moment they can
> only be stored locally on the Radiator servers. Perhaps integration with
> popular 3rd party solutions (such as CyberArk) if their API permits it.
read discussions on the list - if stored elsewhere there are still security
issues. what are you hoping to fix/resolve?
you can store configs on a remote DB if there are basic local issues (though
anyone with admin access could still read the
DB credentials and then connect to the DB to get hold of config).
alan
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Questions regarding new release and current roadmap
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? > 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. > 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
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? > 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. > 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
Re: [RADIATOR] ServerTACACSPLUS logging improvements
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. Note: the peer name log message is now logged as a WARNING instead of ERR. > 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? 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
Re: [RADIATOR] Questions regarding new release and current roadmap
Hi, > 2.5) A method of synchronizing configuration files (apart from certain > variables) across multiple servers. If all Radiator servers have very similar > configuration and are distributed for load balancing and redundancy, it's a > shame that the configuration needs to be managed and configured separately > for each server. There are differences between servers, but the bulk of the > configuration can remain the same. > > There is 3rd party software such as rsync for synchronizing files, but the > variables for each Radiator configuration file have to be within the file > itself (as far as I can tell). If the variables could be configured outside > of each configuration file, such as a header file, this would allow for > synchronizing the configuration files effectively across all servers while > still taking into account the differences between each server. eh??? we do multi server configuration syncing already - you know that you can just include different files for each server...using...a headerfile as you say - our radius.cfg contains all local requirements and then pulls in the local config file for the server. (in our case we use a database to hold all details, generate the required new configs for each server then push out to each server) > 2.6) A more secure method for storing credentials, at the moment they can > only be stored locally on the Radiator servers. Perhaps integration with > popular 3rd party solutions (such as CyberArk) if their API permits it. read discussions on the list - if stored elsewhere there are still security issues. what are you hoping to fix/resolve? you can store configs on a remote DB if there are basic local issues (though anyone with admin access could still read the DB credentials and then connect to the DB to get hold of config). alan _______ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Questions regarding new release and current roadmap
Hi Heikki, Thanks for the update. 1) Any news on uploading the roadmap? 2) Thanks for taking an interest. The features I'm interested in are the following: 2.1) OCSP + OCSP stapling. I've heard this is on the roadmap for the near future. 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. 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). 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. 2.5) A method of synchronizing configuration files (apart from certain variables) across multiple servers. If all Radiator servers have very similar configuration and are distributed for load balancing and redundancy, it's a shame that the configuration needs to be managed and configured separately for each server. There are differences between servers, but the bulk of the configuration can remain the same. There is 3rd party software such as rsync for synchronizing files, but the variables for each Radiator configuration file have to be within the file itself (as far as I can tell). If the variables could be configured outside of each configuration file, such as a header file, this would allow for synchronizing the configuration files effectively across all servers while still taking into account the differences between each server. 2.6) A more secure method for storing credentials, at the moment they can only be stored locally on the Radiator servers. Perhaps integration with popular 3rd party solutions (such as CyberArk) if their API permits it. That's my wishlist :) ________ From: radiator-boun...@open.com.au [radiator-boun...@open.com.au] on behalf of Heikki Vatiainen [h...@open.com.au] Sent: Friday, June 10, 2016 11:26 AM To: radiator@open.com.au Subject: Re: [RADIATOR] Questions regarding new release and current roadmap On 7.6.2016 19.56, Nadav Hod wrote: > 1) It's been awhile since 4.16 was released, I was wondering if there is > a candidate release date for the next version. If you have valid download access for the full or evaluation version, you can download the current patch set to see what's currently intended for the next release. There's no candidate release date yet. We are currently using the patched version heavily ourselves and we are aiming for the release during this summer. > 2_ For those of us who won't be in London for 5G World, is there any > chance of disclosing the roadmap for Radiator soon after? Is there something you are particulary interested in? I'll ask the others here about publishing more information about the upcoming features. There's nothing secret about the roadmap :) 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
Re: [RADIATOR] Is the Radiator NFV customizable?
Thanks for the detailed response, Tuure :) Any chance OSC will be creating a video for NFV installation on OpenStack/ESXi in the near future? From: radiator-boun...@open.com.au [radiator-boun...@open.com.au] on behalf of Tuure Vartiainen [varti...@open.com.au] Sent: Tuesday, June 28, 2016 10:43 AM To: radiator@open.com.au Subject: Re: [RADIATOR] Is the Radiator NFV customizable? Hello, > On 27 Jun 2016, at 10:34, Nadav Hod wrote: > > I have the impression that the VNF is much like an appliance, where the only > interface the user has with the VNF is the configuration file. I was hoping > the amazing Radiator team could clear up the following issues: > yes, VNF is a kind of an software appliance which is meant to be configured through different interfaces. > 1) Is the operating system (CentOS if I recall correctly) fully writeable so > that other applications can interface with Radiator (such as logrotate, rsync > etc.)? > Yes. Radiator VNF is not restricted to using CentOS, but we are using CentOS as a base Linux distribution for Radiator VNF. Adaptation for Ubuntu/Debian will require some work but it is feasible. > 2) Can patches (including security) be applied to the underlying OS? Does > this void warranty? > Yes, patches can be applied and do not void warranty/support. > 3) Are there any common use cases when it's best not to use Radiator as NFV? > Radiator VNF is meant for AAA cases which require scaling for performance, either automatically or manually. > 4) Does the VNF include all the common perl modules necessary for Radiator? > Can more be installed and updated? > Yes. Modules can be updated and more modules can be installed. > 5) What are the specs for the VNF? Is there any resource allocation necessary > from the hypervisor's side? > Radiator VNF does not have any strict requirements. Currently we are running Radiator VNF on OpenStack, but it can also be adapted to run on a bare metal hardware or in VMware vCloud. Default minimum HA setup of Radiator VNF consists of 11 virtual machines: - 2 Radiator load balancers (RADIUS or Diameter) - 2 Radiator AAA workers (number of workers scales according to load) - 3 Database/message broker nodes - 2 External database connector nodes (LDAP, SQL, RADIUS or Diameter) - 2 Management nodes With OpenStack, creating Radiator VNF stack is automated through its Heat orchestration. 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 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ServerTACACSPLUS logging improvements
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] Is the Radiator NFV customizable?
Hello, > On 27 Jun 2016, at 10:34, Nadav Hod wrote: > > I have the impression that the VNF is much like an appliance, where the only > interface the user has with the VNF is the configuration file. I was hoping > the amazing Radiator team could clear up the following issues: > yes, VNF is a kind of an software appliance which is meant to be configured through different interfaces. > 1) Is the operating system (CentOS if I recall correctly) fully writeable so > that other applications can interface with Radiator (such as logrotate, rsync > etc.)? > Yes. Radiator VNF is not restricted to using CentOS, but we are using CentOS as a base Linux distribution for Radiator VNF. Adaptation for Ubuntu/Debian will require some work but it is feasible. > 2) Can patches (including security) be applied to the underlying OS? Does > this void warranty? > Yes, patches can be applied and do not void warranty/support. > 3) Are there any common use cases when it's best not to use Radiator as NFV? > Radiator VNF is meant for AAA cases which require scaling for performance, either automatically or manually. > 4) Does the VNF include all the common perl modules necessary for Radiator? > Can more be installed and updated? > Yes. Modules can be updated and more modules can be installed. > 5) What are the specs for the VNF? Is there any resource allocation necessary > from the hypervisor's side? > Radiator VNF does not have any strict requirements. Currently we are running Radiator VNF on OpenStack, but it can also be adapted to run on a bare metal hardware or in VMware vCloud. Default minimum HA setup of Radiator VNF consists of 11 virtual machines: - 2 Radiator load balancers (RADIUS or Diameter) - 2 Radiator AAA workers (number of workers scales according to load) - 3 Database/message broker nodes - 2 External database connector nodes (LDAP, SQL, RADIUS or Diameter) - 2 Management nodes With OpenStack, creating Radiator VNF stack is automated through its Heat orchestration. 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
[RADIATOR] Is the Radiator NFV customizable?
Hi everyone, I have the impression that the VNF is much like an appliance, where the only interface the user has with the VNF is the configuration file. I was hoping the amazing Radiator team could clear up the following issues: 1) Is the operating system (CentOS if I recall correctly) fully writeable so that other applications can interface with Radiator (such as logrotate, rsync etc.)? 2) Can patches (including security) be applied to the underlying OS? Does this void warranty? 3) Are there any common use cases when it's best not to use Radiator as NFV? 4) Does the VNF include all the common perl modules necessary for Radiator? Can more be installed and updated? 5) What are the specs for the VNF? Is there any resource allocation necessary from the hypervisor's side? If anyone has other questions regarding Radiator NFV, feel free to piggyback on this thread. Thanks! ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ServerTACACSPLUS logging improvements
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? Thanks for your comments, Heikki -- Heikki Vatiainen h...@open.com.au ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] OTP Authentication failed logging
On 24.06.2016 13:50, Hartmaier Alexander wrote: > Will you change the log message? Yes. I forgot to say that. >> 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. The default check is simply a test if the submitted password equals the expected password, so there's not much to log. I was thinking about possible cases where the checks are different and additional logging would be useful. Thanks, Heikki -- Heikki Vatiainen h...@open.com.au _______ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ServerTACACSPLUS logging improvements
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
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
Re: [RADIATOR] OTP Authentication failed logging
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. I'd say the best option is to log any failure reason in the OTP's VerifyHook if any special logs are needed. Thanks for notifying us about this! Heikki -- Heikki Vatiainen h...@open.com.au _______ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Suggestion: Should an InfluxDB log handler be implemented, it should support batching data points
Hi everyone, Earlier this month the subject of performance monitoring with grafana came up. I for one would be very happy to see this implemented in Radiator in order to have the logs stored in a consolidated manner (assuming the database supports clustering), and readable by graphing applications. Heikki's proof of concept for InfluxDB (posted February 2016 in the mailing list), which opens a separate socket for each message, looks like a good start. I would like to suggest that a log handler for InfluxDB should be written, and if so that it allows for batching multiple data points instead of writing one line per socket. This should provide much better performance according to Influx's website. Link to suggestion: https://docs.influxdata.com/influxdb/v0.13/guides/writing_data/ ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ServerTACACSPLUS logging improvements
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. Thanks, Heikki -- Heikki Vatiainen h...@open.com.au _______ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] OTP Authentication failed logging
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] Multiple accounting output formats
Hello, AcctLog would be a very handy feature for us too. Regards Vangelis On 14/6/2016 11:47 πμ, Tuure Vartiainen wrote: > Hi, > >> On 13 Jun 2016, at 18:13, >> wrote: >> >> What I would like to achieve is the following: from a single handler >> generate accounting logs to multiple files in multiple formats (e.g. 2 files >> with the normal output, 1 with JSON output). Outputting to multiple files is >> easy, but of course adding the formatting hook for JSON output causes both >> files to be in that format. >> Is there any way to achieve this in radiator? (It’s not a problem for >> Authentication logs since you can just set a different log filename per e.g. >> AuthBy, but this does not seem to be available for accounting logs). >> > unfortunately currently that’s not possible, all AcctLogFileNames use the > same > configured format. > > AuthLog could be companied with AcctLog which would allow to configure the > described feature. > > > BR ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Multiple accounting output formats
Hi, > On 13 Jun 2016, at 18:13, > wrote: > > What I would like to achieve is the following: from a single handler generate > accounting logs to multiple files in multiple formats (e.g. 2 files with the > normal output, 1 with JSON output). Outputting to multiple files is easy, but > of course adding the formatting hook for JSON output causes both files to be > in that format. > Is there any way to achieve this in radiator? (It’s not a problem for > Authentication logs since you can just set a different log filename per e.g. > AuthBy, but this does not seem to be available for accounting logs). > unfortunately currently that’s not possible, all AcctLogFileNames use the same configured format. AuthLog could be companied with AcctLog which would allow to configure the described feature. 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
[RADIATOR] Multiple accounting output formats
Hello Everyone, After getting some inspiration from the most recent Radiator Cookbook blog post i’ve been working on generating JSON logging from radiator; this itself has been very successful but i’ve now run into a problem regarding accounting. What I would like to achieve is the following: from a single handler generate accounting logs to multiple files in multiple formats (e.g. 2 files with the normal output, 1 with JSON output). Outputting to multiple files is easy, but of course adding the formatting hook for JSON output causes both files to be in that format. Is there any way to achieve this in radiator? (It’s not a problem for Authentication logs since you can just set a different log filename per e.g. AuthBy, but this does not seem to be available for accounting logs). Kind regards, Leon Haverkotte | Network engineer | University of Twente | Library, ICT Services & Archive (LISA) / ITO | Campus building Citadel, room H219 | T: +31 (0)53 - 489 3016 | l.m.c.haverko...@utwente.nl | www.utwente.nl/lisa smime.p7s Description: S/MIME cryptographic signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ServerTACACSPLUS logging improvements
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] Redback BRAS _ Radiator _ GPON network
Hello Thomas - If the Redback Smartedge BRAS can be configured to send RADIUS interim accounting updates, then yes you can configure Radiator to handle them. Note that this is totally dependent on the Redback device, so you will need to check their documentation. regards Hugh > On 11 Jun 2016, at 01:52, Thomas Kurian wrote: > > Dear Support, > > We have a client who is basically an ISP with GPON network connected to > Ministry of Communication, Redback Smartedge BRAS and Radiator Radius server. > Currently their radiator is handling their customers authentication. Kindly > advise whether it is possible to send interim accounting updates from Redback > BRAS NAS to a new radiator radius server in order to identify the top > bandwidth abuser customer company sharing the GPON leased line on an hourly > basis. > > For example : Lets say the ISP has leased a 10Mbps connection from the > ministry of communication for a set of 10 various customer companies. > > Lets assume the average bandwidth consumption per company is 1Mbps. Lets say > from 1-2pm , 2nd company fully uses the 10Mbps bandwidth and therefore > during this hour the rest of the 9 companies cannot use this connection, > hence we need to identify these leased line abuser companies on a hourly > basis and put them under a separate tariff plan in order to provide them a > dedicated line to fulfill their bandwidth needs as per their consumption > rates. Currently since the ISP GPON network terminates at the ministry of > communication from where it is distributed to the customer companies, the ISP > does not have visibility on the top bandwidth abuser company as a lump-sum. > > Please advise whether having a new radiator installation instance which > receives interim accounting updates from Redback BRAS NAS server with a > customized GUI to review top abuser companies on a hourly basis or should we > consider to go for some additional product integration such as Solarwinds NPM > to achieve the above mentioned objective. > > -- > Best Regards, > > Thomas Kurian > IT Security Consultant > Kuwaiti Canadian Consulting Group (www.kccg.com) > T: +965 22435566 > F: +965 22415149 > E:tho...@kccg.com > > -- 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] Redback BRAS _ Radiator _ GPON network
Dear Support, We have a client who is basically an ISP with GPON network connected to Ministry of Communication, Redback Smartedge BRAS and Radiator Radius server. Currently their radiator is handling their customers authentication. Kindly advise whether it is possible to send interim accounting updates from Redback BRAS NAS to a new radiator radius server in order to identify the top bandwidth abuser customer company sharing the GPON leased line on an hourly basis. For example : Lets say the ISP has leased a 10Mbps connection from the ministry of communication for a set of 10 various customer companies. Lets assume the average bandwidth consumption per company is 1Mbps. Lets say from 1-2pm , 2nd company fully uses the 10Mbps bandwidth and therefore during this hour the rest of the 9 companies cannot use this connection, hence we need to identify these leased line abuser companies on a hourly basis and put them under a separate tariff plan in order to provide them a dedicated line to fulfill their bandwidth needs as per their consumption rates. Currently since the ISP GPON network terminates at the ministry of communication from where it is distributed to the customer companies, the ISP does not have visibility on the top bandwidth abuser company as a lump-sum. Please advise whether having a new radiator installation instance which receives interim accounting updates from Redback BRAS NAS server with a customized GUI to review top abuser companies on a hourly basis or should we consider to go for some additional product integration such as Solarwinds NPM to achieve the above mentioned objective. -- Best Regards, Thomas Kurian IT Security Consultant Kuwaiti Canadian Consulting Group (www.kccg.com) T: +965 22435566 F: +965 22415149 E:tho...@kccg.com ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Questions regarding new release and current roadmap
On 7.6.2016 19.56, Nadav Hod wrote: > 1) It's been awhile since 4.16 was released, I was wondering if there is > a candidate release date for the next version. If you have valid download access for the full or evaluation version, you can download the current patch set to see what's currently intended for the next release. There's no candidate release date yet. We are currently using the patched version heavily ourselves and we are aiming for the release during this summer. > 2_ For those of us who won't be in London for 5G World, is there any > chance of disclosing the roadmap for Radiator soon after? Is there something you are particulary interested in? I'll ask the others here about publishing more information about the upcoming features. There's nothing secret about the roadmap :) 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
Re: [RADIATOR] ServerTACACSPLUS logging improvements
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). 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. 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
Re: [RADIATOR] ServerTACACSPLUS logging improvements
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
[RADIATOR] Questions regarding new release and current roadmap
Hi everyone, 1) It's been awhile since 4.16 was released, I was wondering if there is a candidate release date for the next version. 2_ For those of us who won't be in London for 5G World, is there any chance of disclosing the roadmap for Radiator soon after? Thanks :) ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Blog post: Make your Radiator log data searchable
Hello all, just wanted to highlight a post from our Radiator Cookbook blog: http://radiatorcookbook.open.com.au/2016/06/make-your-radiator-log-data-searchable.html In the post, we described how Radiator log data can be exported in JSON format and how it can be made as useful as possible. It is also our plan to post more these kind of articles about interesting Radiator use cases in the future as well - hopefully they will be useful to many Radiator users. Best regards, Jaakko Stenhall Open System Consultants j...@open.com.au ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Automated Reply : Thomas Kurian is out of station
Dear Sender, Thank you for your e-mail. Kindly be informed that I am currently out of station and will be back on Sunday June 5th 2016. During this period, I'll have no access to e-mails and limited phone access. For matters requiring immediate attention, you are kindly requested to contact Mr. Hakim for both General Sales and Technical support queries. Contact Details are as follows : Mr Hakim's Email ID : ha...@kccg.com KCCG Office Phone No. : +965 22435566 -- Best Regards, Thomas Kurian IT Security Consultant Kuwaiti Canadian Consulting Group (www.kccg.com) T: +965 22435566 F: +965 22415149 E: tho...@kccg.com ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ServerTACACSPLUS logging improvements
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. 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, 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
Re: [RADIATOR] ServerTACACSPLUS logging improvements
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
Re: [RADIATOR] ServerTACACSPLUS logging improvements
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. > 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. > - Authorization permitted for $USERNAME at $IPADDR, group $GROUPNAME, > args service=shell cmd* Should be possible, not completely sure yet though. > 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 -- 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
Re: [RADIATOR] Support for OCSP
On 17.5.2016 10.40, Jan Tomasek wrote: >> Authority Information Access: >> OCSP - URI:http://ocsp.int-x1.letsencrypt.org/ >> CA Issuers - URI:http://cert.int-x1.letsencrypt.org/ > > I've found discusion from 2012 [1] and main reason is no longer true. > Net::SSLeay do support OCSP today [2] > > For EAP-TLS OCSP delay might be issue but for RadSec connection not, I > think. Please can you reconsider adding OCSP support? Hello Jan, thanks for getting back to OCSP support. As an update, we have preliminary code for doing OCSP lookups during certificate. This can be used to build basic OCSP lookup support in RadSec. After looking at Let's Encrypt and how OCSP is used with Let's Encrypt certificates in more detail, it appears OCSP stapling, or more officially Certificate Status extension defined in RFC 6066, might be something that RadSec could benefit from. However, it looks like server side support needs more bindings in Net::SSLeay so server side OCSP will take longer to implement. Net::SSLeay seems to have the necessary bindings for client side support, so if that could be made available first, if it is useful by itself without the server side OCSP stapling support. I will get back to this once there's working code. 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] ServerTACACSPLUS logging improvements
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
