Re: [RADIATOR] Huawei VSAs
On 2014-02-04 14:57, Heikki Vatiainen wrote: > On 02/03/2014 02:27 PM, Hartmaier Alexander wrote: > >> I've added some more Huawei VSAs to the dictionary, please include them >> in the standard dictionary file, thanks! > Done. Thanks. > >> VENDORATTR2011Huawei-Requested-APN168string >> VENDORATTR2011Huawei-GGSN-Vendor232string >> VENDORATTR2011Huawei-GGSN-Vendor233string > Do 232 and 233 have the same name? Sorry, my bad, it's Version, not Vendor: VENDORATTR2011Huawei-GGSN-Version233string > > Heikki > *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] R: LDAP shadowExpire
Thanks Robert,
I tried to use a PostSearchHook like the documentation example; but with a
get_reply instead the your get_check
and it didn't work
This is "my" working Hook:
PostSearchHook sub {
my $shadowExpire = @{$_[4]->get('shadowExpire')}[0] ;
$_[3]->get_check->add_attr('Expiration', $shadowExpire * 86400
);
}
Thanks again
--
Fabio
-Messaggio originale-
Da: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] Per
conto di Robert Fisher
Inviato: martedì 4 febbraio 2014 19.39
A: radiator@open.com.au
Oggetto: Re: [RADIATOR] LDAP shadowExpire
You could accomplish this in a PostSearchHook. The documentation
includes an example for adding a reply item based off a multiplied value, so
guessing something like:
PostSearchHook sub {
my $shadowExpire = $_[4]->get('shadowExpire');
$_[3]->get_check->add_attr("Expiration", $shadowExpire * 86400); }
Robert Fisher
Systems Administrator
Sitestar Internet Services
On 2/4/2014 10:11 AM, Fabio Prina wrote:
> Hi All,
>
> I'm using posixAccount/shadowAccount users in a LDAP and I would like
> to use the shadowExpire attribute to check the Expiration ... but the
> value is expressed days since the 01/01/1970 and not seconds
>
> Maybe is a stupid question but is there a way to use this attribute?
> Like multiply by 86400 before the check
>
> Thanks
> --
> Fabio
> ___
> 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 mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Vlan assigned by ldap group membership on radiator,
Hi, 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 ? Can anyone enlight me on this. Thanks in advance -- Pedro Miguel Marques. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] multiple EAP-TLS AuthBys
That worked like a charm!
Thanks Heikki!
Is this because of historical reasons?
On 2014-02-04 14:54, Heikki Vatiainen wrote:
> On 02/03/2014 06:46 PM, Hartmaier Alexander wrote:
>
>>> You might be able to use EAPTLS_CertificateVerifyHook to check which CA
>>> matched. However, I have not checked in detail if this is possible. I
>>> would first see if the requests have any information that could help
>>> with Handler selection.
>> I already wrote a handler but the weird things are:
>> - $matchedcn is undefined. Is this because I'm doing AuthBy FILE with
>> AcceptIfMissing or because of EAPTLS_NoCheckId?
> I think it's because of EAPTLS_NoCheckId. There might be still a way to
> use EAPTLS_CertificateCerifyHook, even with this option enabled.
>
>> - I don't have access to the reply packed in the hook which makes
>> assigning a different value to the Tunnel-Private-Group-ID attribute
>> more complicated than necessary.
> You could use $p->{EAPContext} to store the information. It would then
> be available when the authentication finishes. The reply when the hook
> runs would be for Access-Challenge, not for the final Access-Accept.
>
> You could try this. In the EAPTLS_CertificateVerifyHook store the
> certificate issuer in the context and return for example, 'DEFAULT'.
I return the cert issuer's name as the return value isn't processed any
further.
I tried to put the radius reply attribute into the users file and create
one user per company but that didn't work out either.
>
> $_[5]->{EAPContext}->{cert_issuer} =
> Net::SSLeay::X509_NAME_oneline(Net::SSLeay::X509_get_issuer_name($_[2]));
I saw that $_[5]->{EAPContext} is a Radius::Context object. Is there an
API for hook added values so I don't accidentally overwrite a Radiator
internal attribute?
>
> In PostAuthHook map the issuer name to VLAN id when the result is
> ACCEPT. Then use $rp->add_attr() to add Tunnel-Private-Group-ID with the
> value off VLAN id.
The one odd thing is that some hooks like for example the PostAuthHook
get their params as references which doesn't allow
my ($p, $rp, $result) = @_;
but you have to derefernce them instead like
my $p = ${$p};
>
> This might work especially if there are not too many issuers and issuer
> is enough to establish which CA is used. Otherwise more complete
> certificate chain walk would be required.
I have only the direct issuing certs in the cert directory, so I don't
have to check the cert chain.
>
> Thanks,
> Heikki
>
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] IPv6 enhancements in current patches: IPV6_V6ONLY and IPv6 CIDR clients
On 2013-11-30 22:40, Heikki Vatiainen wrote: > On 11/29/2013 04:04 PM, Hartmaier Alexander wrote: > >> I've just read the IPv6 section in the 4.12.1 reference manual after >> installing 4.12.1 on a new RHEL6 box which has IPv6 support disabled via >> 'alias ipv6 off' and 'options ipv6 disable=1' in /etc/modprobe.d/local.conf. >> >> On startup Radiator logs: 'INFO: This system is IPv6 capable. IPv6 >> capability provided by: core' although the Socket6 module isn't >> installed because its tests fail because IPv6 support is disabled in the >> Linux kernel. > That's interesting. Does Socket6 compilation really check if IPv6 is > disabled in the system? > > The Radiator log message is about the IPv6 capability of the Perl that > was used to invoke radiusd. Now that you mentioned, it might be better > to say that the system has IPv6 capable Perl and the Perl IPv6 > capability required by Radiator is provided by Perl core (or Socket6 or > none). > > In your case, even if you can not use BindAddress ::, radiusd can still > process attributes with IPv6 addresses and prefixes without problems > since the Perl core libraries have support for e.g., getaddrinfo(). > >> But the manual says 'Note: Currently IPv6 support requires Socket6.pm >> Perl module.'. Which one is correct, the manual or the log message? > The manual is correct for Radiator 4.12.1 as it was released. Binding to > IPv6 addresses, address packing and other functions and decoding and > encoding of IPv6 addresses and prefix in attributes requires Socket6.pm > with 4.12.1. In a recent p5p mailing list discussion Paul Evans confirmed that Socket6 isn't needed these days as the core Socket has all functions required: https://rt.perl.org/Public/Bug/Display.html?id=75740#txn-1278801 Please rework Radiator's code to use a new-enough Socket.pm instead of the deprecated Socket6.pm, thanks! If everything goes well IO::Socket::IP will be in core Perl 5 Version 20, which will be released in March, as a replacement for IO::Socket::INET to provide IPv4 and IPv6 support. So if you're using ::INET today please replace it with ::IP and test it. You can also use Acme::Override::INET to override all ::INET with ::IP calls. > > The patches in 4.12.1 check Perl's IPv6 capability and try to prefer the > built in core modules. If the core does not support all the required > functionality, then presence of Socket6.pm is checked. If there is no > Socket6.pm either then IPv6 addresses and prefixes can not be encoded > and decoded in human readable format and are processed as binary data > which works for proxying. That already sounds like it's using Socket instead of Socket6. I recommend to remove Socket6 at all and require a newer Socket.pm instead. > >> The Perl version is 5.16.3 compiled on the box using perlbrew. > Perl 5.16.3 is recent enough, I think 5.14.0 has everything required, so > radiusd finds the core modules in 5.16.3 can be used. Also, since you > get the log message about IPv6 capability, it means you have Radiator > 4.12.1 + patches. > >> The very first sentence doesn't mention TACACS+, does it support IPv6 >> too or not? > ServerTACACSPLUS should work with IPv6. Looks like > goodies/tacacsplustest does not support IPv6 for testing yet, but the > server side should work. Good to know, thanks! > >> Please add this info. > The documentation regarding Socket6.pm not required for recent enough > Perls will be in the next release's documentation. We can also mention > TACACS+ too. > > Thanks, > Heikki > > -- > Heikki Vatiainen > > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, > TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, > DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, > NetWare etc. > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
