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

[Hartmaier Alexander]

On 2014-02-06 23:11, Heikki Vatiainen wrote:
> On 10/11/2013 11:38 AM, Alexander Hartmaier wrote:
>
>> our switching guys reported that their Cisco Nexus switches running
>> NX-OS log that their can't reach the tacacs servers. This is what the
>> troubleshooting brought up:
>>
>> 2013 Oct 11 08:47:37.061 sgv20s %TACACS-3-TACACS_ERROR_MESSAGE: All
>> servers failed to respond
> Returning to the subject with new information. This problem was seen by
> others too and this time a fix seems to be found.
>
> The bug appears to be CSCtz32293 and is corrected in 5.2(1)N1(5). The
> upgrade was done to 5.2(1)N1(6) which shows no problems.
>
> A similar looking problem is also described here:
> http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080c17808.shtml
>
> I'm not sure if this relates to Steve's problem but looks exactly what
> Alexander was seeing.
Thanks for keeping track of this problem!!!
I had no time to further investigate it with our switching guys but
informed them about the update.

>
> Thanks,
> Heikki
>



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

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

[Heikki Vatiainen]

On 10/11/2013 11:38 AM, Alexander Hartmaier wrote:

> our switching guys reported that their Cisco Nexus switches running
> NX-OS log that their can't reach the tacacs servers. This is what the
> troubleshooting brought up:
> 
> 2013 Oct 11 08:47:37.061 sgv20s %TACACS-3-TACACS_ERROR_MESSAGE: All
> servers failed to respond

Returning to the subject with new information. This problem was seen by
others too and this time a fix seems to be found.

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

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

I'm not sure if this relates to Steve's problem but looks exactly what
Alexander was seeing.

Thanks,
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] Log messages

[Michael Hulko]

We're seeing the following, not quite so frequently in our logs.  Not every 
server is reporting this.  Can anyone confirm that this is simply a client 
trying to authenticate with an unsupported EAP type?

Feb 5 11:32:53 riptide-6.vm.its.uwo.pri /usr/bin/radiusd[14112]: Could not load 
EAP module Radius::EAP_0: Can't locate Radius/EAP
_0.pm in @INC (@INC contains: . /usr/local/lib64/perl5 /usr/local/share/perl5 
/usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor
_perl /usr/lib64/perl5 /usr/share/perl5 .) at (eval 11750293) line 3,  
line 2747056.
Feb 5 11:32:53 riptide-6.vm.its.uwo.pri /usr/bin/radiusd[14112]: Could not load 
EAP module Radius::EAP_0: Can't locate Radius/EAP
_0.pm in @INC (@INC contains: . /usr/local/lib64/perl5 /usr/local/share/perl5 
/usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor
_perl /usr/lib64/perl5 /usr/share/perl5 .) at (eval 11750293) line 3,  
line 2747056.

Thanks

Michael Hulko
Network Analyst

Western University Canada
Network Operations Centre
Information Technology Services
1393 Western Road, SSB 3300CC
London, Ontario  N6G 1G9

tel: 519-661-2111 x81390
e-mail: mihu...@uwo.ca 





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

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

[Heikki Vatiainen]

On 02/05/2014 08:07 PM, Hartmaier Alexander wrote:

> In a recent p5p mailing list discussion Paul Evans confirmed that
> Socket6 isn't needed these days as the core Socket has all functions
> required:
> https://rt.perl.org/Public/Bug/Display.html?id=75740#txn-1278801

I agree. The latest Perls do not require Socket6.pm to be used anymore
if IPv6 is needed.

> Please rework Radiator's code to use a new-enough Socket.pm instead of
> the deprecated Socket6.pm, thanks!

The current patches already default to Socket.pm. Socket6.pm is only
used if Socket.pm is not current enough.

> If everything goes well IO::Socket::IP will be in core Perl 5 Version
> 20, which will be released in March, as a replacement for
> IO::Socket::INET to provide IPv4 and IPv6 support.
> So if you're using ::INET today please replace it with ::IP and test it.
> You can also use Acme::Override::INET to override all ::INET with ::IP
> calls.

IO::Socket::INET, or IO::Socket::INET6 are not used much by Radiator.
Whatever the dependencies for those are, thet are likely to come from
the modules Radiator uses.

> That already sounds like it's using Socket instead of Socket6. I
> recommend to remove Socket6 at all and require a newer Socket.pm instead.

Socket6 is not required with 4.12.1+patches anymore. Only if Socket does
not have enough functionality, then Socket6 is needed. And even if
Socket6 is missing, any IPv6 typed attributes can still be proxied, and
processed as binary values. Binding to IPv6 addresses does not work,
though if Socket is not recent enough and Socket6 is not installed.

I do not think we will start to require recent enough Socket.pm always.
What is happening is that we do not require Socket6.pm. If Socket.pm is
not recent enough, then the user can install Socket6 or newer Socket.
I'd say that is easier because Socket6.pm is already packaged by many OS
vendors, such as RedHat for RHEL6.

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

goodies/tacacsplustest also supports IPv6 now. However, it is one of the
IO::Socket::I* users and requires IO::Socket::INET6 if IPv6 connections
are needed :)

An option might be to make it try IO::Socket::IP first before defaulting
back to IO::Socket::INET6 or ::INET.

If you plan to test the latest patches, please let us know how it goes
without Socket6.pm

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] Vlan assigned by ldap group membership on radiator,

[Heikki Vatiainen]

On 02/05/2014 02:20 PM, Pedro Marques wrote:

> I need to do the following config on radiator server . For each user
> authentication request, i want to verfify ldap user group membership ,
> and according to the ldapgroup i want to change the
> " Tunnel-Private-Group-ID"  in the radiator reply.
> What is the best aproach to do that ?

The simple approach is to have an attribute for each user. The attribute
value is the VLAN id and no group lookup is required.

If you need to do a group lookup, you could utilise PostSearchHook to do
additional queries. Based on the query results, you can push
Tunnel-Private-Group with the VLAN id value in the user's reply
attributes. There was discussion related to this just a few days ago on
this list.

If you can query the groups the user is member of, you could store those
in the reply with AuthAttrDef. A PostAuthHook could then map the group
information to VLAN id. However, this would work the best when the final
Access-Accept is returned right after the LDAP lookup. This is not the
case with for example, PEAP.

The details depend on how the data is presented in your directory. Some
sites map group names to VLAN ids and some sites even have the VLAN id
as a part of group name. The id is then extracted from the group name
directly.

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