Re: [RADIATOR] DEBUG logging oddities
Hi Heikki, Am 18.02.2016 um 12:37 schrieb Heikki Vatiainen: > On 18.2.2016 12.40, Karl Gaissmaier wrote: > >> no official solution or ACK for this problem til now :-( > > Huh, almost a week already. I have no official solution, but I can tell > what we have been up to recently. The virtualisation work we have done > has brought up similar requirements as what you describe. Don't hesitate > to let us if you have comments on this. see it as a compliment. With 'normal' companies such delays and even much longer delays or total ignorance are 'normal', but not for the RADIATOR team! For me it's enough to hear that you ACKed my problem as a general problem and yes, both points (recv/sent messages log and stateful Ids) sounds fine. Best Regards Charly RADIATOR, the software with the world best supporting team! ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] DEBUG logging oddities
Hi,
no official solution or ACK for this problem til now :-(
Currently I use the following homebrew workaround to get debug messages
with trace level 4 in private log clauses:
# Gimmick to trick ::willLog
# has an unnecessary processing component, I know, but ...
Trace 4
Identifier NULL-LOGGER-GIMMICK
Filename/dev/null
# more global loggers for errors, warnings and notices:
Trace 2
Identifier radiatorlog
Filename%L/radiatorlog
Trace 2
IgnorePacketTrace
...
Best Regards
Charly
> Hi RADIATOR Team,
>
> I would like to dump the packet attributes within ServerRADSEC or
> AuthRADSEC but without overwhelming packet hexdumps.
>
> Therefore I can't/won't use PacketTrace in the clauses.
>
> I configured a clause specific Logger with 'Trace 4' but the 'sub
> main::willLog' doesn't honor the settings in the clause loggers, instead
> it checks just the global logger(s) und shortcuts the calls to
> recv_debug_dump in the Modules:
>
>> Radius/AuthRADIUS.pm: $p->recv_debug_dump($self) if
>> (main::willLog($main::LOG_DEBUG, $p));
>> Radius/AuthRADSEC.pm: $p->recv_debug_dump($self) if
>> (main::willLog($main::LOG_DEBUG, $p));
>> Radius/Client.pm: $p->recv_debug_dump($self) if
>> (main::willLog($main::LOG_DEBUG, $p));
>> Radius/ServerRADSEC.pm: $tp->recv_debug_dump($self) if
>> (main::willLog($main::LOG_DEBUG, $tp));
>>
>> #
>> # Return true if at least one logger is required to log
>> # Can be a shortcut to prevent length logging calculations
>> sub main::willLog
>> {
>>my ($priority, $p) = @_;
>> return 1
>>if ($main::config->{LogStdout}&& ($priority <= $main::config->{Trace}
>> || ($p && $p->{PacketTrace})))
>> || grep $_->willLog($priority, $p), @{$main::config->{Log}};
>> }
>
>
>
> Please see my stripped down test setting:
>
>
>> BindAddress 127.0.0.1
>> AuthPort 1812
>> AcctPort 1813
>>
>> LogDir /tmp/radiator/log
>> DbDir /tmp/radiator/etc
>>
>>
>> # disable global logfile for tests, in production I use a global file logger
>> and syslog logger with Trace 2
>> LogFile
>> # I'll just see warnings and errors in the global log or during this tests
>> on stdout
>> Trace 2
>> Foreground
>> LogStdout
>>
>> PidFile%D/radiusd.pid
>> DictionaryFile %D/my-very-short-dict-for-running-under-perl-debugger
>>
>> # AuthBy gimmick to define referable, non global loggers, thanks Hugh!
>>
>>
>> Identifier DEBUG-LOGGER
>> Trace 4
>> Filename %L/debug-logger
>>
>>
>>
>>
>>Identifier AUTHBY_TEST
>>
>>
>>
>># I'm interested in the radius code and attributes, not in SSL hexdumps
>>Log DEBUG-LOGGER
>>Secret radsec
>>Identifier AUTHBY_RADSEC
>>
>>UseStatusServerForFailureDetect
>>KeepaliveTimeout 10
>>FailureBackoffTime 10
>>NoreplyTimeout 10
>>
>>LocalAddress 127.0.0.1
>>Host 127.0.0.1
>>
>># test settings, in production use valid certs and CN checks!!!
>>UseTLS
>>TLS_CAFile %D/certificates/demoCA/cacert.pem
>>TLS_ExpectedPeerName .*
>>
>>TLS_CertificateFile %D/certificates/cert-clt.pem
>>TLS_CertificateType PEM
>>TLS_PrivateKeyFile %D/certificates/cert-clt.pem
>>TLS_PrivateKeyPassword whatever
>>
>>
>> #
>>
>>
>>Identifier HANDLER_FROM_RADSEC
>>AuthBy AUTHBY_TEST
>>
>>
>>
>>Identifier HANDLER_TO_RADSEC
>>AuthBy AUTHBY_RADSEC
>>
>>
>>
>>Identifier HANDLER_DEFAULT
>>AuthBy AUTHBY_TEST
>>
>>
>> #
>>
>>
>>Identifier DEFAULT
>>Secret mysecret
>>Log DEBUG-LOGGER
>>
>>
>>
>># I'm interested in the radius code and attributes, not in SSL hexdumps
>>Log DEBUG-LOGGER
>>
>>Identifier RADSEC_SERVER
>>BindAddress 127.0.0.1
>>Port 2083
>>Secret radsec
>>
>>AddToRequest Connect-Info=RADSEC
>>AddToReply Connect-Info=RADSEC
>>
>>UseTLS
>>TLS_CAFile %D/certificates/demoCA/cacert.pem
>>TLS_CertificateFile %D/certificates/cert-srv.pem
>>TLS_CertificateType PEM
>>TLS_PrivateKeyFile %D/certificates/cert-srv.pem
>>TLS_PrivateKeyPassword whatever
>>TLS_RequireClientCert
>>TLS_ExpectedPeerName .*
>>
>>
>
>
>
> and then test it with radpwtst
>
>> $ radpwtst -bind_address 127.0.0.1 -s 127.0.0.1 -noacct -auth_port 1812
>> -user foo@radsec
>
> Any hint how to solve this problem?
>
> Please rethink your ::willLog(...) and btw, in my opinion, the
> whole logging deserves refactoring ;-(
[RADIATOR] DEBUG logging oddities
Hi RADIATOR Team,
I would like to dump the packet attributes within ServerRADSEC or
AuthRADSEC but without overwhelming packet hexdumps.
Therefore I can't/won't use PacketTrace in the clauses.
I configured a clause specific Logger with 'Trace 4' but the 'sub
main::willLog' doesn't honor the settings in the clause loggers, instead
it checks just the global logger(s) und shortcuts the calls to
recv_debug_dump in the Modules:
> Radius/AuthRADIUS.pm: $p->recv_debug_dump($self) if
> (main::willLog($main::LOG_DEBUG, $p));
> Radius/AuthRADSEC.pm: $p->recv_debug_dump($self) if
> (main::willLog($main::LOG_DEBUG, $p));
> Radius/Client.pm: $p->recv_debug_dump($self) if
> (main::willLog($main::LOG_DEBUG, $p));
> Radius/ServerRADSEC.pm: $tp->recv_debug_dump($self) if
> (main::willLog($main::LOG_DEBUG, $tp));
>
> #
> # Return true if at least one logger is required to log
> # Can be a shortcut to prevent length logging calculations
> sub main::willLog
> {
> my ($priority, $p) = @_;
> return 1
> if ($main::config->{LogStdout}&& ($priority <= $main::config->{Trace}
> || ($p && $p->{PacketTrace})))
> || grep $_->willLog($priority, $p), @{$main::config->{Log}};
> }
Please see my stripped down test setting:
> BindAddress 127.0.0.1
> AuthPort 1812
> AcctPort 1813
>
> LogDir /tmp/radiator/log
> DbDir /tmp/radiator/etc
>
>
> # disable global logfile for tests, in production I use a global file logger
> and syslog logger with Trace 2
> LogFile
> # I'll just see warnings and errors in the global log or during this tests on
> stdout
> Trace 2
> Foreground
> LogStdout
>
> PidFile%D/radiusd.pid
> DictionaryFile %D/my-very-short-dict-for-running-under-perl-debugger
>
> # AuthBy gimmick to define referable, non global loggers, thanks Hugh!
>
>
> Identifier DEBUG-LOGGER
> Trace 4
> Filename %L/debug-logger
>
>
>
>
> Identifier AUTHBY_TEST
>
>
>
> # I'm interested in the radius code and attributes, not in SSL hexdumps
> Log DEBUG-LOGGER
> Secret radsec
> Identifier AUTHBY_RADSEC
>
> UseStatusServerForFailureDetect
> KeepaliveTimeout 10
> FailureBackoffTime 10
> NoreplyTimeout 10
>
> LocalAddress 127.0.0.1
> Host 127.0.0.1
>
> # test settings, in production use valid certs and CN checks!!!
> UseTLS
> TLS_CAFile %D/certificates/demoCA/cacert.pem
> TLS_ExpectedPeerName .*
>
> TLS_CertificateFile %D/certificates/cert-clt.pem
> TLS_CertificateType PEM
> TLS_PrivateKeyFile %D/certificates/cert-clt.pem
> TLS_PrivateKeyPassword whatever
>
>
> #
>
>
> Identifier HANDLER_FROM_RADSEC
> AuthBy AUTHBY_TEST
>
>
>
> Identifier HANDLER_TO_RADSEC
> AuthBy AUTHBY_RADSEC
>
>
>
> Identifier HANDLER_DEFAULT
> AuthBy AUTHBY_TEST
>
>
> #
>
>
> Identifier DEFAULT
> Secret mysecret
> Log DEBUG-LOGGER
>
>
>
> # I'm interested in the radius code and attributes, not in SSL hexdumps
> Log DEBUG-LOGGER
>
> Identifier RADSEC_SERVER
> BindAddress 127.0.0.1
> Port 2083
> Secret radsec
>
> AddToRequest Connect-Info=RADSEC
> AddToReply Connect-Info=RADSEC
>
> UseTLS
> TLS_CAFile %D/certificates/demoCA/cacert.pem
> TLS_CertificateFile %D/certificates/cert-srv.pem
> TLS_CertificateType PEM
> TLS_PrivateKeyFile %D/certificates/cert-srv.pem
> TLS_PrivateKeyPassword whatever
> TLS_RequireClientCert
> TLS_ExpectedPeerName .*
>
>
and then test it with radpwtst
> $ radpwtst -bind_address 127.0.0.1 -s 127.0.0.1 -noacct -auth_port 1812 -user
> foo@radsec
Any hint how to solve this problem?
Please rethink your ::willLog(...) and btw, in my opinion, the
whole logging deserves refactoring ;-(
Maybe, supporting module specific $self->willLog would be proper a path
to go.
Best Regards
Charly Gaissmaier
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] small patch for AuthYUBIKEYVALIDATIONSERVER.pm
Hi Heikki, Am 08.02.2016 um 11:17 schrieb Heikki Vatiainen: > On 6.2.2016 14.52, Karl Gaissmaier wrote: > >> there is a little bug in AuthYUBIKEYVALIDATIONSERVER. >> See the applied patch. > Hello Charly, > > have you tried running yhsm-validation-server with the '--short-otp' > command line parameter? I think the problem you see is that Radiator is > expecting a single line response --short-otp generates. We authenticate against the YubiCloud: http://api.yubico.com/wsapi/2.0/verify?id=xxx Maybe we need an additional config Parameter for AuthYUBIKEYVALIDATIONSERVER if we have different response formats. Best Regards Charly -- Karl Gaissmaier Universität Ulm kiz, Kommunikations und Informationszentrum 89069 Ulm Tel.: 49(0)731/50-22499 Fax : 49(0)731/50-12-22499 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] small patch for AuthYUBIKEYVALIDATIONSERVER.pm
Hi RADIATOR team,
there is a little bug in AuthYUBIKEYVALIDATIONSERVER.
See the applied patch.
Best Regards
Charly Gaissmaier
--- /radiator/build/Radiator-4.16/Radius/AuthYUBIKEYVALIDATIONSERVER.pm
Mi. Apr 16 10:01:29 2014
+++ /tmp/AuthYUBIKEYVALIDATIONSERVER.pm Sa. Feb 6 13:47:59 2016
@@ -106,7 +106,7 @@
# HTTP 200
my $decoded_response = $response->decoded_content;
chomp $decoded_response;
-if ($decoded_response =~ /^OK /)
+if ($decoded_response =~ /^status=OK/m)
{
$self->log($main::LOG_DEBUG, "YubiKey $method validation
result: $decoded_response");
return ($main::ACCEPT);
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Request for enhancement: Log Handler InfluxDB or at least UDP
Hi Heikki, thanks for fast reply and interest! Sorry, I was ill, therefore I couldn't answer til yet. Am 29.01.2016 um 18:31 schrieb Heikki Vatiainen: > ... > Yes, this is very interesting. I looked at the line protocol > specification and it should be easy to implement with a formatting hook > for authentication. Accounting should be fairly easy too. > > It might be worth considering a seprate log agent to forward the logs to > InfluxDB (or in genral to other logging, graphing, etc. systems). This > would separate the duties: radiator would create formatted logs and the > agent could handle the actual log forwarding. yes, like heka http://hekad.readthedocs.org as forwarding agent and/or anomaly processor. Heka has also a sandboxed Lua interpreter to decode unusual log formats, maybe I'll not implement the hook in RADIATOR. Maybe it's really enough to create normal logs and use heka (or similar tools) to process anomaly detection and forward it to graphite/influxdb. I'll rethink my request for enhancements. > This would also make it easier to add accounting and debug log > forwarding too since they can already be formatted when written to files. > > If you need help with logformat hook, just let me know. I am interested > in helping you with this. > > If I do it as a RADIATOR hook, I'll come back to your offer. Thank you very much, the RADIATOR team is great! Best Regards Charly -- Karl Gaissmaier Universität Ulm kiz, Kommunikations und Informationszentrum 89069 Ulm Tel.: 49(0)731/50-22499 Fax : 49(0)731/50-12-22499 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Request for enhancement: Log Handler InfluxDB or at least UDP
Hi RADIATOR team, you know, most of us want to 'Measure Anything, Measure Everything' https://codeascraft.com/2011/02/15/measure-anything-measure-everything/ I'm in the process to feed an InfluxDB from RADIATOR logfiles. Much nicer would it be if RADIATOR team would implement: with the very simple but effective line protocol over HTTP or at least an generic with a proper logformat hook done by the users and shipped as goodies. Interested? Have a look at https://blog.haschek.at/post/fc060 Best Regards Charly -- Karl Gaissmaier Universität Ulm kiz, Kommunikations und Informationszentrum 89069 Ulm Tel.: 49(0)731/50-22499 Fax : 49(0)731/50-12-22499 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hello, ... Meanwhile we could/should add a config flag in radsecproxy to allow this. Meanwhile you can put a radsecproxy between your Radiator and let radsecproxy to handle all the request. nope, I'll will not shepherd an additonal daemon. As far as I understood the Radiator team, they will fix AuthBy RADSEC for Status-Server requests in near future. I'll stay with radiator, helping to test it in production network, for failover with Status-Server requests, against a radsecproxy upstream. And when the radsecproxy team has fixed the stripping Proxy-State attribut in replies for Access-, Acct- and Challenge-Requests, (thanks for patching it already in your installation for our peer connection), the incompatibility between radsecproxy and radiator AuthBy RADSEC is history. A lot of other users will benefit from a proper solution. Best Regards Charly -- Karl Gaissmaier Universität Ulm / Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hello, Am 15.07.2013 10:07, schrieb Ralf Paffrath: ... anyway it's a bit proprietary that Radiator ignores the correct identifier in an Access-Reject packet. The Identifier is also part of RFC2865: Identifier The Identifier field is one octet, and aids in matching requests and replies. The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time. in case of connection oriented RADSEC/TCP proxying, it's problem to decide on client addresses and client ports, It's always the same peer socket and 8 bits can be very soon to short on a heavy used proxy connection. RADSEC/TCP or RADIUS/TCP came after RFC-2865, maybe we should make an RFC addendum, that Proxy-State MUST ALWAYS be replied, even in Status-Server requests. Meanwhile we could/should add a config flag in radsecproxy to allow this. Best Regards Charly -- Karl Gaissmaier Universität Ulm / Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hello, Am 15.07.2013 07:47, schrieb Stefan Winter: Hello, Maybe someone can trigger the authors of radsecproxy too, to start implementing Proxy-State RFC 2865 conform when *generating* responses. Seems it makes everthing right on proxying but not on generating packets. Status-Server is defined in RFC5997. It uses a distinct command-code - it's not an Access-Request, it's Status-Server. So all the rules of an Access-Request and corresponding responses are not relevant. In particular, the attribute Proxy-State is not expected to be in there. See section 5 of that RFC. Adding to that, there is also no reason to use Proxy-State at all because Radiator does not act as proxy - it's acting as a simple RADIUS Client, sending an initial request to some other server. Proxy-State (in Access-Requests) only comes into play when a server *receives* a packet from downstream, then sees that it needs to be sent elsewhere still, and then *forwards* it. Only then does it add Proxy-State. None of this is true with Status-Server; and proxying Status-Server packets is prohibited in section 4.4 of that same RFC. this may be true for Status-Server but not for the Access-Rejects generated by the radsecproxy. This has to be corrected by radsecproxy. And yes, Radiator AuthRADSEC has to fix the problem with Status-Server. Both together are incompatible but often used together in eduroam. Greetings Charly -- Karl Gaissmaier Universität Ulm / Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward
Hi, Am 15.07.2013 09:15, schrieb a.l.m.bu...@lboro.ac.uk: Hi, 1272017248108...@wlan.mnc001.mcc262.3gppnetwork.org 3gppnetwork realms are invalid. ..just like hotmail, gmail, yahoo etc - until a notice comes from eduroam stating that these realms now have agreed relationship, they are public realms and not within the private scheme of eduroam. thats's not the point, I had (again) a wrong example choosen. Some users have just typos in their realms, an endpoint eduroam SP can not handle all typos, we proxy it upstream. If the upstream Rejects it, it should not strip the Proxy-State Attribut. RFC 5997, saying that Status-Server MUST NOT be proxied and therefore the Proxy-State attribut isn't allowed. status-server musnt be proxiedits only for the first-hop check of a remote proxy and not the end target - but that surely isnt the issue? a Status-Server message is easy to deal with - you just send something back to show you are alive - RADIATOR has been sending a basic statts page back for status-server queries to it for years. Radiator doesn't proxy the Status-Server requests, he generates it and has a wrong scheme to deal with the limited 8-Bits of Request Identifiers. Again: 1.)Radiator has to fix AuthRADSEC. The user has to choose to use extended-Ids in the Proxy-State Attribut if the upstream proxy will handle this. By default it should use 8 Bit Identifiers. 2.)radsecproxy has to fix the self generated Access-Rejects. If a Proxy-State Attribut was present in the Access-Request, the generated Access-Reject must copy this attribut and send it back. Best Regards Charly -- Karl Gaissmaier Universität Ulm / Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hello, Am 15.07.2013 09:27, schrieb Stefan Winter: Hi, this may be true for Status-Server but not for the Access-Rejects generated by the radsecproxy. This has to be corrected by radsecproxy. And yes, Radiator AuthRADSEC has to fix the problem with Status-Server. Both together are incompatible but often used together in eduroam. Yes, the lack of returning Proxy-State when radsecproxy crafts its own Rejects is definitely a problem of radsecproxy; it violates RFC2865, section 5.33: This Attribute is available to be sent by a proxy server to another server when forwarding an Access-Request and MUST be returned unmodified in the Access-Accept, Access-Reject or Access-Challenge. I've sent a notice to the radsecproxy mailing list, notifying them of the problem. I'm hoping to see a next release with a proper fix. Thanks, you got the point and saved my day! Best Regards Charly -- Karl Gaissmaier Universität Ulm / Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] documentation typo at 13.1.33 DefineFormattedGlobalVarsystem
Hi radiator team, there is a missing whitespace in the documentation: 13.1.33 Variable names prefixed with GlobalVar: The attribute to be compared is taken from a GlobalVar. GlobalVar variables can be set from the command line, or with the DefineFormattedGlobalVar parameter. This can be useful for activating different sets of users in multiple instances of Radiator. # In the config file: DefineFormattedGlobalVarsystem mysystem # in a users file: username Password=fred,GlobalVar:system=mysystem Must be: DefineFormattedGlobalVar system mysystem Best Regards Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] AuthBy RADIUS and UseExtendedIds, stripped Proxy-State and strange behavior after 256 requests
Hi radiator team, still debugging the nasty bug between radsecproxy and Radiator in the eduroam connection between uni-ulm.de and radiusX.dfn.de, sigh! I have the problem with 'AuthBy RADSEC', where always extendid IDs are used. If someone is stripping/mangling the Proxy-State, the reply can't be mapped to the request and the warning is printed: WARNING: Unknown reply received in AuthRADSEC for request from 127.0.0.1:2083 The missing request Id can't mapped, therefore the additional blank in the warning between 'request from'. There is never a PacketTrace so see the buggy answer. A patch will come soon to dump this, but wait and read to the end of my message. Now I looked for the Radiator behavior for AuthBy RADIUS with extended Ids and stripping Proxy-State. Wondering, it worked! ... But only for the first 256 Requests (8-Bits, 0xff mask in code) and after that I got the same/similar warning: WARNING: Unknown reply received in AuthRADIUS for request 0 from 127.0.0.1:1900 ... WARNING: Unknown reply received in AuthRADIUS for request 1 from 127.0.0.1:1900 You see, now the request Id is used from the 8-Bit Packet-Identifier, but could notbe mapped to the Proxy-State ExtendedId, since the 8 Bits wrapped: Proxy-State = OSC-Extended-Id=256 ... Proxy-State = OSC-Extended-Id=257 This is not optimal, since it works for a while after starting radiusd and after 256 requests you get spurious errors. Please fix this, if you UseExtendedIds in AuthBy RADIUS you should always WARN if the Proxy-State is stripped or mangled. And sure, we need better packet dumps in this case to see the sent/missing/mangled attributes in the reply packet. Best Regards Charly -- Karl Gaissmaier Universität Ulm / Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthBy RADIUS and UseExtendedIds, stripped Proxy-State and strange behavior after 256 requests
Hi Heikki, it's sunday, really I can wait for answers from your team after weekend ;-) Am 14.07.2013 10:54, schrieb Heikki Vatiainen: On 07/14/2013 11:30 AM, Karl Gaissmaier wrote: Please fix this, if you UseExtendedIds in AuthBy RADIUS you should always WARN if the Proxy-State is stripped or mangled. Good point. It's a good idea make this separate from getting an unknown reply, which is currently logged for the both cases. And sure, we need better packet dumps in this case to see the sent/missing/mangled attributes in the reply packet. We are actually working on this now. There will be two changes at least: - enable PackeTrace for requests received from AuthBy RADIUS and RADSEC - see that packet dump is called so that any Log ... within AuthBy etc. module will be called instead of the dump going just to the main log file Thanks for Radiator and for this excellent service! Best Regards Charly -- Karl Gaissmaier Universität Ulm / Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthBy RADIUS and UseExtendedIds, stripped Proxy-State and strange behavior after 256 requests
Hi Heikki, Am 14.07.2013 11:35, schrieb Heikki Vatiainen: On 07/14/2013 12:17 PM, Karl Gaissmaier wrote: it's sunday, really I can wait for answers from your team after weekend ;-) Heh, I thought I'd save you some work since I understood you were gointo to work on the debug log and PacketTrace patch. yep, you saved my (sun)day The Proxy-State mangling is a bit problematic, though. This attribute is the only identifier that currently maps responses to requests with RadSec. If the other proxies mangle it, it would be essential to find and fix them. And with RADSEC it's important to dump unknown replies, since the packets are encrypted on wire and without the private-key of the upstream proxy I can't decipher it. I need the dumps from Radiator in the case of 'Unknown replies' even if the attr-values can't be decoded. Best Regards and thanks in advance Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward
Hi radiator team,
now I proved my suspicion, that the upstream radsecproxy is stripping
the radiator proxy-state, at least in status-server requests.
I used monkey patching in AuthBy RADSEC, just quick and dirty
to get the result (you know, it's sunday):
Sun Jul 14 16:56:43 2013 009313: DEBUG: Packet dump:
*** Sending request to RadSec radius2.dfn.de:2083
Code: Status-Server
Identifier: 5
Authentic: 4160179224193233154132+1902O227f205
Attributes:
Message-Authenticator =
Proxy-State = OSC-Extended-Id=5
Sun Jul 14 16:56:43 2013 014566: DEBUG: ### UULM DUMP##
*** Unmatched Ext-Id in Proxy-State for reply in AuthRADSEC from
radius2.dfn.de:2083
Code: Access-Accept
Identifier: 5
Authentic: 24723026254245134C128219p216223I
Attributes:
Sun Jul 14 16:56:51 2013 115473: DEBUG: Packet dump:
*** Sending request to RadSec radius1.dfn.de:2083
Code: Status-Server
Identifier: 6
Authentic: 0217255198172F232131401552162f1{189
Attributes:
Message-Authenticator =
Proxy-State = OSC-Extended-Id=6
Sun Jul 14 16:56:51 2013 138708: DEBUG: ### UULM DUMP##
*** Unmatched Ext-Id in Proxy-State for reply in AuthRADSEC from
radius1.dfn.de:2083
Code: Access-Accept
Identifier: 6
Authentic: 233;136k1879s#200v232208137150Wv
Attributes:
Sun Jul 14 16:56:53 2013 210994: INFO: AuthRADSEC: No reply from
radius2.dfn.de:2083 for Status-Server request ()
Now it's clear, that failover between radsecproxy (used at dfn.de) and
Radiator with status-server keepalives could not work. It took me a long
time and I had to dig into the code, since I could not establish
debugging for returned packets in AuthBy RADSEC in production systems
and TLS encryption is unbreakable for me, I'm not the NSA and not
working for PRISM, sigh.
Question: Do you have a working test setup between radsecproxy and
Radiator for 'UseStatusServerForFailureDetect'?
Can you send me your radsecproxy config and tell me the radsecproxy
version number. I'll will send it to DFN to recheck their config.
Worse, it seems that buggy clients with unroutable @Realms trigger
answers with proxy-state stripped. So I get NoreplyTimeouts for
any buggy client request and my upstream connections break away.
Seems that all german @Realms in eduroam using Radiator have the same
problem, because all of them use the same upstream radsecproxy at DFN,
sigh.
Best Regards
Charly
--
Karl Gaissmaier
Universität Ulm / Germany
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward
Am 14.07.2013 17:28, schrieb Karl Gaissmaier: ... Worse, it seems that buggy clients with unroutable @Realms trigger answers with proxy-state stripped. So I get NoreplyTimeouts for any buggy client request and my upstream connections break away. Seems that all german @Realms in eduroam using Radiator have the same problem, because all of them use the same upstream radsecproxy at DFN, sigh. and here is the prove: Sun Jul 14 17:49:02 2013 177403: DEBUG: Packet dump: *** Sending request to RadSec radius1.dfn.de:2083 Code: Access-Request Identifier: 42 Authentic: U182136130!141232175230y)23442399y Attributes: User-Name = uni.ulm.test@akad Service-Type = Framed-User NAS-IP-Address = 203.63.154.1 NAS-Identifier = 203.63.154.1 NAS-Port = 1234 Called-Station-Id = 123456789 Calling-Station-Id = 987654321 NAS-Port-Type = Async EAP-Message = 200221uni.ulm.test@akad Message-Authenticator = 231+b159G1352147185$N192tw205] Proxy-State = OSC-Extended-Id=42 Sun Jul 14 17:49:02 2013 199902: DEBUG: ### UULM DUMP## *** Unmatched Ext-Id in Proxy-State for reply in AuthRADSEC from radius1.dfn.de:2083 Code: Access-Reject Identifier: 42 Authentic: 246223219M179S234VE2625323625251r17 Attributes: Reply-Message = Misconfigured client! Delete spaces at the end of the realm! again the Proxy-State is stripped, radiator can't match the reply to the request, we get a NoreplyTimeout and the connection goes down afetr some retries. Please test the radiator against radsecproxy in your lab. Best Regards Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward
Hi Alex, hi radiator team, Am 14.07.2013 19:48, schrieb Alan Buxey: Hi As an end site you really shouldn't be sending invalid realms to your national proxy... but there does seem to be something odd gong on here. I sent it to test this situation. As an eduroam ServiceProvider I don't know if a client is misconfigured. OK, nornmally I reject top-level realms, like the used '@akad' in my test, but some visitors have for example: 1272017248108...@wlan.mnc001.mcc262.3gppnetwork.org and this has the same result. As an endpoint SP, I can't filter for all wrong @realms, I don't know them all ,-) . their system should be just sending back a straight access reject. If radsecproxy doesn't like extended proxy id (or the config doesn't allow it ) then that would be an issue Yes, this is the issue. I don't see the config of the federation-level-radius-proxy and the admins are not very helpful, they state, thats a problem with Radiator using extended Ids in the proxy-styte, e.g. they respomg with RFC 5997, saying that Status-Server MUST NOT be proxied and therefore the Proxy-State attribut isn't allowed. 4.4. Proxy Server Handling of Status-Server Many RADIUS servers can act as proxy servers, and can forward requests to another RADIUS server. Such servers MUST NOT proxy Status-Server packets. The purpose of Status-Server as specified here is to permit the client to query the responsiveness of a server with which it has a direct relationship. Proxying Status-Server queries would negate any usefulness that may be gained by implementing support for them. Proxy servers MAY be configured to respond to Status-Server queries from clients, and they MAY act as clients sending Status-Server queries to other servers. However, those activities MUST be independent of one another. What shall I do, Radiators AuthBy RADSEC Identifiers are always based on proxy-State. What does the radiator tesm says about RFC 5997. Best Regards Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hi radiator team, I looked over the radsecproxy sources and sorry to say it: *Currently the radsecproxy and AuthRADSEC are incompatible!* Whenever radsecproxy *generates* a reply message (Access-Reject or Access-Accept on Satus-Server) it never copies the Proxy-State Attribute from the request packet to the reply packet. The only shortcoming solution as far as I see is, we need a 'UseExtendedIds' in Radiator not only for AuthRADIUS but also for AuthRADSEC with a warning, never to use it when proxying to a radsecproxy. Sorry for the bad news. Maybe someone can trigger the authors of radsecproxy too, to start implementing Proxy-State RFC 2865 conform when *generating* responses. Seems it makes everthing right on proxying but not on generating packets. Best Regards Charly -- Karl Gaissmaier Universität Ulm / Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] PacketTrace for Authby RADSEC does not dump receiving packets
OK, I'll be more specific, attached are 2 test configs, one for AuthBy RADSEC and one for a ServerRADSEC. I had to strip down my complex config to show you the problem. If I logg to stdout with a global 'Trace 4', I see the Receiving packets. But I can't do this in production with a server on heavy load. Therefore I configure a logging clause within the AuthBy RADSEC and within the ServerRADSEC, and then I don't see the receiving packets, only the sending packets. Please see the attached logfiles, too. Is this intentional or a bug? Best Regards Charly -- Karl Gaissmaier Universität Ulm/Germany Trace 2 Identifier BASE BindAddress 127.0.0.1 AuthPort1800 AcctPort1801 LogDir . DbDir . PidFile %L/pid-base DictionaryFile %D/dictionary LogFile Log FILE Trace 2 Filename%L/logfile-base /Log Client DEFAULT Secret mysecret StatusServerShowClientDetails /Client Realm DEFAULT AuthBy RADSEC PacketTrace Log FILE Trace 5 Filename%L/logfile-base-debug /Log Host127.0.0.1 Port2083 Secret radsec UseTLS TLS_CAFile ./certificates/demoCA/cacert.pem TLS_ExpectedPeerNameCN=test.server.some.company.com /AuthBy /Realm Trace 2 Identifier UPSTREAM LogDir . DbDir . PidFile %L/pid-upstream DictionaryFile %D/dictionary BindAddress 127.0.0.1 AuthPort1900 AcctPort1901 LogFile Log FILE Trace 2 Filename%L/logfile-upstream /Log Client DEFAULT Secret mysecret StatusServerShowClientDetails /Client Realm DEFAULT AuthBy TEST /AuthBy /Realm ServerRADSEC PacketTrace Log FILE Trace 5 Filename%L/logfile-upstream-debug /Log BindAddress 127.0.0.1 Port2083 Secret radsec Protocoltcp UseTLS TLS_CAFile ./certificates/demoCA/cacert.pem TLS_CertificateFile ./certificates/cert-srv.pem TLS_CertificateType PEM TLS_PrivateKeyFile ./certificates/cert-srv.pem TLS_PrivateKeyPassword whatever TLS_RequireClientCert 0 /ServerRADSEC Sat Jul 13 18:04:48 2013 973161: DEBUG: Handling with Radius::AuthRADSEC Sat Jul 13 18:04:48 2013 974710: DEBUG: Packet dump: *** Sending request to RadSec 127.0.0.1:2083 Code: Access-Request Identifier: 1 Authentic: BEt*$240132140233r2392242458165199 Attributes: User-Name = mike Service-Type = Framed-User NAS-IP-Address = 203.63.154.1 NAS-Identifier = 203.63.154.1 NAS-Port = 1234 Called-Station-Id = 123456789 Calling-Station-Id = 987654321 NAS-Port-Type = Async User-Password = VA230255`2216]172229253163K25227! Proxy-State = OSC-Extended-Id=1 Sat Jul 13 18:04:29 2013 048542: DEBUG: Stream connected to 127.0.0.1:43313 Sat Jul 13 18:04:29 2013 048893: DEBUG: StreamTLS sessionInit for 127.0.0.1 Sat Jul 13 18:04:29 2013 049508: DEBUG: StreamTLS receive: Sat Jul 13 18:04:29 2013 049769: DEBUG: StreamTLS SSL_accept result: -1, 2, 8465 Sat Jul 13 18:04:29 2013 050038: DEBUG: StreamTLS send: Sat Jul 13 18:04:29 2013 050181: DEBUG: StreamTLS Server Started for 127.0.0.1:43313 Sat Jul 13 18:04:29 2013 050272: DEBUG: New StreamServer Connection created for 127.0.0.1:43313 Sat Jul 13 18:04:29 2013 111653: DEBUG: StreamTLS receive: 16030100d801d4030151e17a8d79bd7650e15798a88bf3f389f4437dfc8c6c666ba812e50f24dfde4c66c014c00ac022c0210039003800880087c00fc00500350084c012c008c01cc01b00160013c00dc003000ac013c009c01fc01e00330032009a009900450044c00ec004002f00960041c011c007c00cc002000500040015001200090014001100080006000300ff0145000b000403000102000a00340032000e000d0019000b000c00180009000a00160017000800060007001400150004000500120013000100020003000f00100011000f000101 Sat Jul 13 18:04:29 2013 113062: DEBUG: StreamTLS SSL_accept result: -1, 2, 8576 Sat Jul 13 18:04:29 2013 113578: DEBUG: StreamTLS send: 16030100560252030151e17a8dd5d906ecea5551282a24fed83163e4638dda4dfdbcc6c6ee1d7b7d5920610d6be6a94ce495991a74026bbf5e4b8e3d9555c45f67c2e797dbcfda839a8b00350aff0100010f00010116030107550b00075100074e0002fb308202f730820260a003020102020102300d06092a864886f70d01010505003081ca310b30090603550406130241553111300f06035504081308566963746f72696131123010060355040713094d656c626f75726e65311e301c060355040a13154f53432044656d6f204365727469666963617465733121301f060355040b13185465737420436572746966696361746520536563
[RADIATOR] documentation typo at 5.51.1 DefaultResultACCEPT
Hi radiator team, there is a missing whitespace in the documentation: 5.51.1 DefaultResult Specifies how to reply to any request for which there is no more specific result. The default is to IGNORE. # Accept everything not otherwise specified DefaultResultACCEPT Must be: DefaultResult ACCEPT Best Regards Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] PacketTrace for Authby RADSEC does not dump receiving packets
Hi radiator team, I've a nasty problem between radiator and radsecproxy. I tried to dump the receiving packets by AuthRADSEC, but no chance. Seems that the PakcetTrace flag does not go transfered to the receiving packet. Maybe this is a bug? Please see my config snippet. The same is true for Server RADSEC, I never see Incoming packets dumped: Version 4.11, patches from last week applied. ServerRADSEC Secret radsec Identifier FROM-DFN-PROXY PacketTrace Log FILE Trace 5 Filename%L/radsec-debug-logg LogMicroseconds /Log AddToRequestConnect-Info=FROM-DFN-PROXY UseTLS TLS_CAFile %D/certificates/dfn-ca-chain.crt TLS_CertificateFile %D/certificates/radius.uni-ulm.de.crt TLS_CertificateType PEM TLS_PrivateKeyFile %D/certificates/radius.uni-ulm.de.key /ServerRADSEC AuthBy RADSEC Secret radsec Identifier TO-DFN-PROXY PacketTrace # not working, still searching for the bug in radsecproxy chain, sigh # UseStatusServerForFailureDetect # KeepaliveTimeout 10 Log FILE Trace 5 Filename%L/radsec-debug-logg LogMicroseconds /Log # stupid workaround for open problems with upstream proxy MaxFailedRequests 60 MaxFailedGraceTime 1 FailureBackoffTime 0 NoreplyTimeout 10 NoForwardAccounting StripFromReply Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID LocalAddress134.60.X.Y Hostradius1.dfn.de Hostradius2.dfn.de UseTLS TLS_CAFile %D/certificates/dfn-ca-chain.crt TLS_ExpectedPeerNameCN=.*\.dfn\.de TLS_CertificateFile %D/certificates/radius.uni-ulm.de.crt TLS_CertificateType PEM TLS_PrivateKeyFile %D/certificates/radius.uni-ulm.de.key /AuthBy -- Karl Gaissmaier Universität Ulm/Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] SIGHUP restart and AuthByRADSEC opens an additional socket
Hi, didn't get any response for this request: Am 10.07.2013 11:50, schrieb Karl Gaissmaier: Hi Radiator team, a SIGHUP to a running radiator (Version 4.11) opens an additional socket for AuthByRADSEC: before SIGHUP mizar:.../~# netstat -f inet -P tcp -n | grep 193.*2083 134.60.Y.X.45917 193.174.Y.X.2083 64128 0 128872 0 ESTABLISHED after SIGHUP mizar:.../~# netstat -f inet -P tcp -n | grep 193.*2083 134.60.Y.X.45917 193.174.Y.X.2083 64128 0 128872 0 ESTABLISHED 134.60.Y.X.57680 193.174.Y.X.2083 9792 0 128872 0 ESTABLISHED Please check it whether it's a local oder general problem. Regards Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator 4.11: WARNING: Could not find AuthBy clause with Identifier ...
Hi Heikki,
Am 07.07.2013 21:19, schrieb Heikki Vatiainen:
...
Yes, that seems to be it. Thanks everyone for locating the change. I was
thrown off a bit since I was under the impression it fails with stock
4.11. That's not the case but the change is in the 4.11 patches. It's
also not specific to Solaris either.
We'll see what can be done for this.
the problem, I see with activation during config checks, is only with
socket bindings. As far as I see it's only used in:
Radius/AddressAllocatorDHCP.pm
Radius/ServerRADIUS.pm
Radius/ServerTACACSPLUS.pm
Radius/StreamServer.pm
Maybe you add a condition in this modules during activate() like ...
| Radius/StreamServer.pm, sub activate()
| 93,99c93,103
| bind($s, $paddr)
| || main::log($main::LOG_ERR, Could not bind StreamServer
socket: $!);
| listen($s, Socket::SOMAXCONN)
| || main::log($main::LOG_ERR, Could not listen on StreamServer
socket: $!);
| Radius::Select::add_file(fileno($s), 1, undef, undef,
|\handle_listen_socket_read, $s, $self);
| push(@{$self-{sockets}}, $s);
| ---
| unless ( $self-isCheckingConfiguration ) {
| bind( $s, $paddr )
||| main::log( $main::LOG_ERR,
| Could not bind StreamServer socket: $! );
| listen( $s, Socket::SOMAXCONN )
||| main::log( $main::LOG_ERR,
| Could not listen on StreamServer socket: $! );
| Radius::Select::add_file( fileno($s), 1, undef, undef,
| \handle_listen_socket_read, $s, $self );
| push( @{ $self-{sockets} }, $s );
| }
Maybe we introduce other bugs in distance, sigh.
Best Regards
Charly
--
Karl Gaissmaier
Universität Ulm
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] SIGHUP restart and AuthByRADSEC opens an additional socket
Hi Radiator team, a SIGHUP to a running radiator (Version 4.11) opens an additional socket for AuthByRADSEC: before SIGHUP mizar:.../~# netstat -f inet -P tcp -n | grep 193.*2083 134.60.Y.X.45917 193.174.Y.X.2083 64128 0 128872 0 ESTABLISHED after SIGHUP mizar:.../~# netstat -f inet -P tcp -n | grep 193.*2083 134.60.Y.X.45917 193.174.Y.X.2083 64128 0 128872 0 ESTABLISHED 134.60.Y.X.57680 193.174.Y.X.2083 9792 0 128872 0 ESTABLISHED Please verify it whether it's a general problem. Best Regards Charly -- Karl Gaissmaier Universität Ulm ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] ERR: Stream sysread for radius1.dfn.de:2083 failed: . Peer probably disconnected
Hi radiator team, I tried to upgrade from 4.9 to 4.11 but I had to stop it due to this error: Tue Jul 9 12:42:25 2013: ERR: Stream sysread for radius1.dfn.de:2083 failed: . Peer probably disconnected. Tue Jul 9 12:42:25 2013: ERR: Stream sysread for radius2.dfn.de:2083 failed: . Peer probably disconnected. It's the same perl Installation and the same host/OS: # uname -a SunOS mizar 5.11 11.1 sun4v sparc SUNW,Sun-Fire-T200 # /radiator/perl-5.12.4/bin/perl -v This is perl 5, version 12, subversion 4 (v5.12.4) built for sun4-solaris Hmm, strange. Do you need more infos? Best Regards Charly -- Karl Gaissmaier Universität Ulm 89069 Ulm/Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ERR: Stream sysread for radius1.dfn.de:2083 failed: . Peer probably disconnected
Hi Radiator team,
regression tests are helpful:
git diff Radius/AuthRADSEC.pm for version 4.9 to 4.11:
@@ -119,13 +144,15 @@ sub initialize
my ($self) = @_;
$self-SUPER::initialize;
-$self-{Secret} = 'mysecret';
+$self-{Secret} = 'radsec';
the default secret was changed between 4.9 and 4.11 and I used it, arrgh.
I called the german-toplevel-eduroam-proxy-operator to chnage the
password, and volia it works.
Sorry, I'm sure it's somewhere in the relase notes, but
'read the source luke' is always true.
Best Regards
Charly
--
Karl Gaissmaier
Universität Ulm
89069 Ulm/Germany
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ERR: Stream sysread for radius1.dfn.de:2083 failed: . Peer probably disconnected
Am 09.07.2013 14:04, schrieb Alexander Hartmaier: Using the default isn't secure in any way... it's wihtin RADSEC and not RADIUS. Regards Charly -- Karl Gaissmaier Universität Ulm 89069 Ulm/Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ERR: Stream sysread for radius1.dfn.de:2083 failed: . Peer probably disconnected
Am 09.07.2013 14:32, schrieb Alexander Hartmaier: On 2013-07-09 14:14, Karl Gaissmaier wrote: Am 09.07.2013 14:04, schrieb Alexander Hartmaier: Using the default isn't secure in any way... it's wihtin RADSEC and not RADIUS. So? You can configure the Secret in an AuthBy RADSEC section the same way you can configure it for a ServerRADSEC. sure, but we use RADSEC with TLS, the shared secret is just for compatibility in this case. Regards Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator 4.11: WARNING: Could not find AuthBy clause with Identifier ...
Am 05.07.2013 23:53, schrieb a.l.m.bu...@lboro.ac.uk: Hi, there must be something wrong in your installation or even your config. check the config doesnt have wierd characters in it I guess... 'cat -v /tmp/radiator-config' there were some changes as the move to 4.11 occured to deal with the config strings in better ways - done, no non-printing chars in the file. The next test on monday is a fresh, newer perl installation. What perl version do you have on solaris? Best Regards Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator 4.11: WARNING: Could not find AuthBy clause with Identifier ...
Hi, Am 05.07.2013 23:15, schrieb Christian Kratzer: Hi, just verified your minimal configuration with a clean Radiator-4.11 plus patches installation: thank you very much! there must be something wrong in your installation or even your config. the cfg is clean, 4.9 is working fine # radiusd -c -log_stdout -trace 5 -config_file /tmp/radiator-config Fri Jul 5 18:30:30 2013: WARNING: Could not find AuthBy clause with Identifier myinternal Fri Jul 5 18:30:30 2013: DEBUG: Finished reading configuration file '/tmp/radiator-config' You might want to reverify the minimal configuration. done I typoed Identifier myself a couple of days ago. also checked, and see the minimal stripped down cfg Is above also the error message you get from your full configuration ? the same error messages, for the identifiers in the orig cfg, not only AuthBy identifiers: Sat Jul 6 10:02:34 2013: WARNING: Could not find AuthBy clause with Identifier LDAP-KIZ Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthBy clause with Identifier INTERNAL-SUCCESS Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthBy clause with Identifier LDAP-AKAD Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger-syslog Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthBy clause with Identifier GAST Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger-syslog Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthBy clause with Identifier KIZ Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger-syslog Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger-syslog Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger-syslog Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger-syslog Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger-syslog Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger-syslog Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthBy clause with Identifier KIZ Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger-syslog Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthBy clause with Identifier KIZ Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier authlogger-syslog Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthBy clause with Identifier INTERNAL-SUCCESS Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthBy clause with Identifier AUTH-EDUROAM Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier eduroam-inner-logger Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier eduroam-inner-logger-syslog Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthBy clause with Identifier GAST Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier eduroam-inner-logger Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier eduroam-inner-logger-syslog Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthBy clause with Identifier INTERNAL-REJECT Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier eduroam-inner-logger Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier eduroam-inner-logger-syslog Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthBy clause with Identifier AUTH-MAC-BLACKLIST Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthBy clause with Identifier AUTH-EAP-OUTER Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier eduroam-outer-logger Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthLog clause with Identifier eduroam-outer-logger-syslog Sat Jul 6 10:02:35 2013: WARNING: Could not find AuthBy
Re: [RADIATOR] Radiator 4.11: WARNING: Could not find AuthBy clause with Identifier ...
Hi Heikki, thanks for working an saturday. The Radiator team is as usaual great! Am 06.07.2013 10:21, schrieb Heikki Vatiainen: On 07/06/2013 11:04 AM, Karl Gaissmaier wrote: the cfg is clean, 4.9 is working fine # radiusd -c -log_stdout -trace 5 -config_file /tmp/radiator-config Can you add -foreground option to the options too? And be extra careful to not to miss any complaints that come to stdout only and for that reason won't be visible in the log file afterwards. Fri Jul 5 18:30:30 2013: WARNING: Could not find AuthBy clause with Identifier myinternal Fri Jul 5 18:30:30 2013: DEBUG: Finished reading configuration file '/tmp/radiator-config' You might want to reverify the minimal configuration. I just tried goodies/minimal.cfg with freshly installed Solaris 11.1, September 2012. Perl is 5.12.4 that comes with the system. Radiator is unpatched 4.11. but in the goodies/simple.cfg is no 'Identifier' used. Please add an Identifier and try it again. % perl -I /opt/radiator/current /opt/radiator/current/radiusd -dictionary /opt/radiator/current/dictionary -foreground -log_stdout -config /opt/radiator/current/goodies/simple.cfg Sat Jul 6 11:20:05 2013: DEBUG: Finished reading configuration file '/opt/radiator/current/goodies/simple.cfg' Sat Jul 6 11:20:05 2013: DEBUG: Reading dictionary file '/opt/radiator/current/dictionary' Sat Jul 6 11:20:05 2013: DEBUG: Creating authentication port 0.0.0.0:1645 Sat Jul 6 11:20:05 2013: DEBUG: Creating accounting port 0.0.0.0:1646 Sat Jul 6 11:20:05 2013: NOTICE: Server started: Radiator 4.11 on solaris11 The WARNING comes *only* with the -c (config file check): foobar# /radiator/perl-5.12.4/bin/perl -I /radiator/install-4.11/lib/site_perl/ /radiator/install-4.11/bin/radiusd -log_stdout -trace 5 -config_file /tmp/radiator-config Sat Jul 6 11:37:53 2013: DEBUG: Finished reading configuration file '/tmp/radiator-config' Sat Jul 6 11:37:53 2013: DEBUG: Reading dictionary file './dictionary' Sat Jul 6 11:37:53 2013: DEBUG: Creating authentication port 0.0.0.0:1645 Sat Jul 6 11:37:53 2013: DEBUG: Creating accounting port 0.0.0.0:1646 Sat Jul 6 11:37:53 2013: NOTICE: Server started: Radiator 4.11 on mizar BUT now with -c foobar# /radiator/perl-5.12.4/bin/perl -I /radiator/install-4.11/lib/site_perl/ /radiator/install-4.11/bin/radiusd -c -log_stdout -trace 5 -config_file /tmp/radiator-config Sat Jul 6 11:38:56 2013: WARNING: Could not find AuthBy clause with Identifier myinternal Sat Jul 6 11:38:56 2013: DEBUG: Finished reading configuration file '/tmp/radiator-config' Thanks for your help! Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator 4.11: WARNING: Could not find AuthBy clause with Identifier ...
Hi together, I tried it now with 4.11 *without* patches. All other parameters are identical, and now the config file check with Identifiers work. mizar:.../tmp# /radiator/perl-5.12.4/bin/perl -I /radiator/install-4.11/lib/site_perl/ /radiator/install-4.11/bin/radiusd -c -log_stdout -trace 5 -config_file /tmp/radiator-config Sat Jul 6 15:09:02 2013: DEBUG: Finished reading configuration file '/tmp/radiator-config' The bug must be introduced by the patches 4.11. Best Regards Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator 4.11: WARNING: Could not find AuthBy clause with Identifier ...
Am 06.07.2013 15:51, schrieb a.l.m.bu...@lboro.ac.uk:
Hi,
2013-04-30 Configurable.pm
Configuration file check no longer activates clauses which could cause
spurious error messages.
Requested by Garry Shtern.
?
could it just be that the configuration checker has a b0rkeness
as the server runs okay when NOT using '-c' ?
yep, found in Configurable.pm
#
# Load a particular class module and construct and return an instance
# return undef if it didnt work
sub load
{
my ($file, $class, @args) = @_;
my $ret;
return unless eval(require $class) ($ret = $class-new($file,
@args));
$ret-activate() unless $ret-isCheckingConfiguration();
return $ret;
}
The object does no longer get activated if we are in check config mode,
and the WARNING comes from findAndUse() later on.
Best Regards
Charly
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator 4.11: WARNING: Could not find AuthBy clause with Identifier ...
Hi, until now I checked my old cfg for new Radiaror versions before I upgraded to the newer version in production. With this bug it's not possible to do this any more. Worse, if the AuthBy clause is really missing, the warning is the same. Am 06.07.2013 19:53, schrieb Garry Shtern: When you have activate() in config checking some of the modules, namely all of the ones extending StreamServer will attempt to bind to a port. Obviously, if you have nothing running when doing config check, this is really not a big deal. However, if you simply want to check configuration before restarting your instance, it will cause spurious errors. To overcome the spurious errors in config check mode they have to find a different solution instead of not activating the modules, sorry. For me it's important to check my complex config without getting wrong errors. I'm sure, the Radiator team will find a solution for both problems. Best Regards and thanks for all the responses and help Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Radiator 4.11: WARNING: Could not find AuthBy clause with Identifier ...
Hi RADIATOR team, I tried to upgrade from 4.9 to 4.11 (up to date patches applied) and I'm no longer able to parse my old cfg file. Identifiers are no longer recognized. I stripped it down to the bare minimum: Foreground LogStdout LogDir . DbDir . Trace 4 AuthBy INTERNAL Identifier myinternal AuthResult REJECT /AuthBy Client DEFAULT Secret mysecret /Client Realm DEFAULT AuthBy myinternal /Handler and I get still the following WARNING: # radiusd -c -log_stdout -trace 5 -config_file /tmp/radiator-config Fri Jul 5 18:30:30 2013: WARNING: Could not find AuthBy clause with Identifier myinternal Fri Jul 5 18:30:30 2013: DEBUG: Finished reading configuration file '/tmp/radiator-config' Please check if it's a current bug or if it's my fault. OS: SunOS foobar 5.11 11.1 sun4v sparc SUNW,Sun-Fire-T200 perl -v:perl 5, version 12, subversion 4 (v5.12.4) built for sun4-solaris radiusd -v: This is Radiator 4.11 on foobar Best Regards Charly -- Karl Gaissmaier Universität Ulm kiz, Kommunikations und Informationszentrum 89069 Ulm Tel.: 49(0)731/50-22499 Fax : 49(0)731/50-12-22499 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator 4.11: WARNING: Could not find AuthBy clause with Identifier ...
Hi Christian, RADIATOR team and listeners, Am 05.07.2013 18:57, schrieb Christian Kratzer: ... just saw that you start with: Realm DEFAULT and close with: /Handler uups, sorry but in my original cfg there isn't such a typo and if I correct this stupid error it's the same problem as before. sounds fishy. How did you perform the update ? It's solaris, I use an own perl installation only for RADIATOR in order not to depend on the system /usr/bin/perl with the needed CPAN modules for RADIATOR. The perl installation is the same for Radiator-4.9 and 4.11. I install it via: untar thew 4.11 tgz to /radiator/build-4.11 cd /radiator/build-4.11 untar the 4.11 patches # /special/perl-path/bin/perl Makefile.PL PREFIX=/radiator/install-4.11 # make # make test # make install # make clean and then to test the new installation with this special perl and with this special INCLUDE path: /special/perl-path/bin/perl -I /radiator/install-4.11/lib/site_perl/ /radiator/install-4.11/bin/radiusd -c -log_stdout -trace 5 -config_file /tmp/radiator-config Did it again, checked the files and rights and still the same error. BTW, it's not the first time that I update it in this way. Sounds really fishy, just wondering if someone else sees the same problem. Above configuration should most certainly work. Could be you have a strange mix of old, new and partially installed Radius modules and perhaps multiple versions of radiusd on your system. What does following show: find / -name Radius.pm find / -name AuthINTERNAL.pm find / -name radiusd foobar# find /radiator/ -name Radius.pm /radiator/build/Radiator-4.9/Radius/Radius.pm /radiator/build/Radiator-4.11/Radius/Radius.pm /radiator/install-4.9/lib/site_perl/5.12.4/Radius/Radius.pm /radiator/install-4.11/lib/site_perl/5.12.4/Radius/Radius.pm foobar# find /radiator/ -name radiusd /radiator/build/Radiator-4.9/radiusd /radiator/build/Radiator-4.11/radiusd /radiator/install-4.9/bin/radiusd /radiator/install-4.11/bin/radiusd foobar# find /radiator/ -name AuthINTERNAL.pm /radiator/build/Radiator-4.9/Radius/AuthINTERNAL.pm /radiator/build/Radiator-4.11/Radius/AuthINTERNAL.pm /radiator/install-4.9/lib/site_perl/5.12.4/Radius/AuthINTERNAL.pm /radiator/install-4.11/lib/site_perl/5.12.4/Radius/AuthINTERNAL.pm Everything as expected and often done during the last 10++ years Thanks for your help and hints so far Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] RADSEC, failure algorithm, eduroaming and long reply times
Hello Heikki, Am 05.04.2012 21:19, schrieb Heikki Vatiainen: ... Thanks for clarifying this. I see what you mean. The interest is not in dead realm marking or determining the reachability of a realm somewhere down the proxy chain, but just the health of next hop. In other words, is radius1.dfn.de responding to Server-Status or not. If not, the radius2.dfn.de should be used. This is how I understand it. yep thats what I'm looking for. This is similar done in radsecproxy with the 'statusServer' option, please see in their implementation: http://software.uninett.no/radsecproxy/ and serverStatus ... What I am thinking if an option to return Access-Reject would be needed when your server sees a timeout while trying to forward the request. In other words, there are two things I am thinking of: 1) Status-Server to poll next hop I suggest a new implementation for this case similar to radsecproxy 2) what to do when a request times out. yep this are two cases, I'm looking for case 1.) since I'm the first one in the proxy chain. Maybe you should allow the users of radiator to choose what algo to use. The current algo is OK in a peer2peer situation and the new statusServer algo is needed in a proxy chain. Stay with algo 2 as is and allow to choose statusServer as an option. If the user enables statusServer the failure algo no longer uses NoreplyTimeout as a switchover, thats all. Instead use a StatusServerTimeout, and let all other hooks as is. Then we users can determine what to do when the next-server is down (StatusServerTimeout) and what to do if the Access-Request times out (NoreplyTimeout), but don't use NoreplyTimeout inherently for next-hop failure algo if StatusServer is choosen by the user. About 2): Currently nothing is done. If an Access-Reject is returned then at least the server that forwarded us the request (previous server) would see as being alive. If it can use Status-Server, then Access-Reject would not be needed to signal your server is still alive and was not the reason for the timeout. I don't think you should change this behaviour, stay with it. ... Ok. How about using Status-Server to see if the next hop is alive and DRM to try if the destination realm is reachable by some other route? I am trying to get an idea if DRM has been deemed unnecessary in eduroam use. As I know, our NREN next-hop radius (DFN, german research network) is using radsecproxy. Interestingly, radsecproxies uses serverStatus and RADIATOR - as the next hop - answers properly as a server but don't uses Status-Requests as client. BTW, all what I wrote about AuthBy RADSEC belongs also to AuthBy RADIUS or all other AuthBy proxies! ... I think I understand what you need. I was just trying to clarify if Status-Server would be enough or if anything else is needed too. Thanks Heikki for your patience and the rest of your team for RADIATOR too. Best Regards Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] RADSEC, failure algorithm, eduroaming and long reply times
Hi Heikki, thanks for your fast reply! The radiator team is great! Am 05.04.2012 14:00, schrieb Heikki Vatiainen: On 04/03/2012 07:45 PM, Karl Gaissmaier wrote: Hello Charly, I've a problem with AuthBy RADSEC and the failure algorithm. In the eduroam confederation it's nearly impossible to find proper values for NoreplyTimeout, MaxFailedRequests, ... for Access-Requests. It takes sometimes many seconds (till 60s or more) to get an reply for an Access-Request. It would be much better to use Status-Requests against the server to determine if the next server is dead and not an timeout for proxied Access-Requests down the lane. So Status-Server would be used instead of NoReplyTimeout and MaxFailedRequests? If Status-Server gets no response, then the server would be probed infrequently to see when it gets back. Meanwhile the requests would be forwarded to the secondary server? Please see my config chunk: AuthBy RADSEC Hostradius1.dfn.de Hostradius2.dfn.de FailureBackoffTime 2 MaxFailedRequests 1 NoreplyTimeout 45 UseTLS # TLS specific cfg follows /AuthBy I've increased NoreplyTimeout to a big number, since the reply time - Accept or Reject - can't be estimated nor calculated for the whole Radius Server Hops involved in eduroam. If only one organization has a misbehaving radius server with long delays the failure algorithm used with RADIATOR stops all Eduroam proxying from my organization to my up level NREN radius servers, even if they are proper responding. The mistake is, that the NoreplyTimeout is used to determine if the next radius server is down. The NoreplyTimeout says something about the health of the last radius server for this realm, but the failure algo. kills the running connection to my next-hop NREN server. Thats fatal. This failure algorithm is only useful, if the next-hop radius server is at the end in the proxy chain. It is totally useless and harmful in the eduroam radius chain. Would the current behaviour of returning nothing (IGNORE) to the previous server still be fine? Hm, I didn't catch you? My suggestion would be and additional Parameter like CheckServerStatus: AuthBy RADSEC Hostradius1.dfn.de Hostradius2.dfn.de PollServerStatuson # use Server-Status Requests Pollfrequency 5 # any 5s FailureBackoffTime 2 ... /AuthBy Another alternative would be to synthesise an Access-Reject to the previous server. I don't understand what you mean with 'previous server'. Maybe I'm wrong, but the current failure algo is broken for a radius chain and only useful between peers. Related to this, what is the current view of using Dead Realm Marking in eduroam? Maybe it's useful for NREN radius servers and not for universities. And by the way it's the wrong end to solve the problem. We need an algorithm to check the status of the next-hop radius server and not indirect via a reply timeout from a totally different server down the proxy lane. Maybe I can't explain the problem due to my bad english, but please try to solve this problem in correspondence with me, since it's a real problem. Please see in your history, I don't claim often and when I claim it's normally a real world problem. Best Regards Charly -- Karl Gaissmaier Kommunikations und Informationszentrum kiz der Universität Ulm Abteilung Infrastruktur SG Netzwerk und Telekommunikation 89069 Ulm Tel.: 49(0)731/50-22499 Fax : 49(0)731/50-1222499 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] RADSEC, failure algorithm, eduroaming and long reply times
Hi RADIATOR team, I've a problem with AuthBy RADSEC and the failure algorithm. In the eduroam confederation it's nearly impossible to find proper values for NoreplyTimeout, MaxFailedRequests, ... for Access-Requests. It takes sometimes many seconds (till 60s or more) to get an reply for an Access-Request. It would be much better to use Status-Requests against the server to determine if the next server is dead and not an timeout for proxied Access-Requests down the lane. Is this a new RFE? How is this solved in other eduroam sites with RADIATOR? Best Regards and thanks for RADIATOR, the best software I've ever bought! Charly -- Karl Gaissmaier Kommunikations und Informationszentrum kiz der Universität Ulm Abteilung Infrastruktur SG Netzwerk und Telekommunikation 89069 Ulm Tel.: 49(0)731/50-22499 Fax : 49(0)731/50-1222499 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthBy LDAP2, HoldServerConnection and missing Retry parameter
Hi Heikki, Am 12.04.2011 14:09, schrieb Heikki Vatiainen: On 04/11/2011 12:26 PM, Karl Gaissmaier wrote: this is strange as Radiator-4.x has explicit support for reconnecting to ldap servers after an idle timeout. Indeed. The function that has ldap search for ... error message does LDAP reconnect as the first thing. Reconnect should notice the closed connection and then connect again. but not with HoldSeverConnection, or? I don't see a reconnect, not under Trace 4 and even not on the wire with wireshark. With HoldServerConnection, yes. When HoldServerConnection is defined and there should be an active ldap handle, the code checks if the socket is still ok or it the socket indicates that there is something available. If this something is LDAP_OPERATIONS_ERROR with Unexpected EOF then there should be a reconnect. really strange. I didn't see this. After the LDAP upgrade I'll come back to this problem and keep you informed. Best Regards Charly -- Karl Gaissmaier Kommunikations und Informationszentrum kiz der Universität Ulm Abteilung Infrastruktur SG Netzwerk und Telekommunikation 89069 Ulm Tel.: 49(0)731/50-22499 Fax : 49(0)731/50-1222499 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthBy LDAP2, HoldServerConnection and missing Retry parameter
Hello, thanks for your reply! Am 06.04.2011 23:44, schrieb Heikki Vatiainen: On 04/06/2011 03:39 PM, Christian Kratzer wrote: Wed Apr 6 00:32:34 2011: ERR: ldap search for (|(mail=foo)(uid=bar)) failed with error LDAP_SERVER_DOWN. Wed Apr 6 00:32:34 2011: ERR: Disconnecting from LDAP server (server foo.uni-ulm.de:636). Wed Apr 6 00:32:34 2011: DEBUG: AuthBy LDAP2 result: IGNORE, User database access error this is strange as Radiator-4.x has explicit support for reconnecting to ldap servers after an idle timeout. Indeed. The function that has ldap search for ... error message does LDAP reconnect as the first thing. Reconnect should notice the closed connection and then connect again. but not with HoldSeverConnection, or? I don't see a reconnect, not under Trace 4 and even not on the wire with wireshark. It might be a good idea to upgrade since the newer versions might do better job with sending notices about the disonnect. The LDAP Server isn't under my management domain. But I'll suggest an upgrade. If upgrade is not possible, then commenting out HoldServerConnection will probably help too. done, yep this helps but it's not the best solution under heavy load. .. Perhaps as you only have one ldap server to forward to you should set FailureBackoffTime to 0 to allow radiator to immediatly to reconnect. This didn't help. Best Regards Charly -- Karl Gaissmaier Kommunikations und Informationszentrum kiz der Universität Ulm Abteilung Infrastruktur SG Netzwerk und Telekommunikation 89069 Ulm Tel.: 49(0)731/50-22499 Fax : 49(0)731/50-1222499 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] AuthBy LDAP2, HoldServerConnection and missing Retry parameter
Hi RADIATOR team, I've got a problem with Version 4.7 and AuthBy LDAP2. The LDAP server terminates the connection after 10min of client idle as configured in slapd.conf. Seems that the RADIATOR doesn't recognize this, and the first ACCESS-REQUEST after this termination gets the following error: Wed Apr 6 00:32:34 2011: ERR: ldap search for (|(mail=foo)(uid=bar)) failed with error LDAP_SERVER_DOWN. Wed Apr 6 00:32:34 2011: ERR: Disconnecting from LDAP server (server foo.uni-ulm.de:636). Wed Apr 6 00:32:34 2011: DEBUG: AuthBy LDAP2 result: IGNORE, User database access error See the config part below: AuthBy LDAP2 PacketTrace HoldServerConnection NoDefault Hostfoo.uni-ulm.de Version 3 FailureBackoffTime 3 UseSSL SSLVerify require SSLCAFile %D/certificates/ca-bundle.crt AuthDN cn=secret AuthPasswordmore-secret BaseDN ou=bar,dc=uni-ulm,dc=de Scope one # username oder e-mail SearchFilter(|(mail=%1)(uid=%1)) PasswordAttruserPassword /AuthBy The next ACCEES-REQUEST opens the LDAP connection again, but the first one after the disconnect didn't get the chance to retry: Wed Apr 6 00:20:21 2011: INFO: Connecting to foo.uni-ulm.de:636 Wed Apr 6 00:20:21 2011: INFO: Attempting to bind to LDAP server foo.uni-ulm.de:636 Wed Apr 6 00:20:21 2011: DEBUG: LDAP got result for uid=... First: The RADIATOR does not recognize the termination by the LDAP server Second: There is no 'Retry' parameter for AuthBy LDAP2 for such a case. Any tip welcome. Maybe I've to disable 'HoldServerConnection' until there is an other solution. Best Regards Charly HINTS: I didn't see this problem with RADIATOR 3.11. Sigh, I can't go back to 3.11 to verify it definitely. Sigh, I know, it's a big step from 3.11 to 4.7. The LDAP server didn't change during the RADIATOR upgrade. We are using an openldap-2.3.35 under SunOS 5.10 and openssl-0.9.8-latest. -- Karl Gaissmaier Kommunikations und Informationszentrum kiz der Universität Ulm Abteilung Infrastruktur SG Netzwerk und Telekommunikation 89069 Ulm Tel.: 49(0)731/50-22499 Fax : 49(0)731/50-1222499 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Feature missing: PacketTrace in ServerRADSEC clause
Hi RADIATOR team, I get an ERR: Unknown keyword 'PacketTrace' if I use this declaration in a ServerRADSEC clause. This is a pity, since I can't even decode the packets with wireshark because we UseTLS. PacketTrace is really needed especially within this clause. Please support it in one of the next releases. Best Regards Charly -- Karl Gaissmaier Kommunikations und Informationszentrum kiz der Universität Ulm Abteilung Infrastruktur SG Netzwerk und Telekommunikation 89069 Ulm Tel.: 49(0)731/50-22499 Fax : 49(0)731/50-1222499 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] radpwtest for EAP/TTL, EAP/TTLS and PEAP
Hello, Am 22.03.2011 00:12, schrieb Alan Buxey: Hi, EAP/TTLS, EAP/TLS or PEAP configurations are heavily used in eduroaming institutions. Would be very helpfull if we could monitor our federation config via cron with the help of a scriptable radius checker. are your users using those methodsor is this a case of checking that your install wont bork such requests? it's for me, to monitor my eduroam installation and radsec connections to the german toplevel radius servers with nagios. eapol_test from the wpa_supplicant package can do lots of good things My nagios installation is running under Solaris 10 und I think wpa_supplicant may not be supported for Solaris 10. Would be nice if RADIATOR could test all supported AuthBy Handlers with the radpwtest. Best Regards Charly -- Karl Gaissmaier Kommunikations und Informationszentrum kiz der Universität Ulm Abteilung Infrastruktur SG Netzwerk und Telekommunikation 89069 Ulm Tel.: 49(0)731/50-22499 Fax : 49(0)731/50-1222499 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] radpwtest for EAP/TTL, EAP/TTLS and PEAP
Hi RADIATOR team, is it possible with radpwtest to check a radiator config for EAP/TTLS-PAP? Maybe I just don't find the proper parameters for radpwtest, any hint welcome. If not already coded, please see this as a feature request. EAP/TTLS, EAP/TLS or PEAP configurations are heavily used in eduroaming institutions. Would be very helpfull if we could monitor our federation config via cron with the help of a scriptable radius checker. Best Regards Charly -- Karl Gaissmaier Kommunikations und Informationszentrum kiz der Universität Ulm Abteilung Infrastruktur SG Netzwerk und Telekommunikation 89069 Ulm Tel.: 49(0)731/50-22499 Fax : 49(0)731/50-1222499 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] wrong error message in Radius::StreamServer
Hello RADIATOR team, I stumbled upon a wrong error message. Radiator version 4.7, latest patches. Fri Mar 18 14:07:48 2011: ERR: ServerHTTP has UseSSL/UseTLS, but could not load required modules: Can't locate Digest/HMAC_MD5.pm in @INC (@INC contains: . /radiator/install/lib/site_perl/5.8.5/sun4-solaris /radiator/install/lib/site_perl/5.8.5 /radiator/install/lib/site_perl /radiator/perl-5.8.5/lib/5.8.5/sun4-solaris /radiator/perl-5.8.5/lib/5.8.5 /radiator/perl-5.8.5/lib/site_perl/5.8.5/sun4-solaris /radiator/perl-5.8.5/lib/site_perl/5.8.5 /radiator/perl-5.8.5/lib/site_perl .) at /radiator/install/lib/site_perl/5.8.5/Radius/TLS.pm line 142. But there is no ServerHTTP configured, instead there is a ServerRADSEC configured. Looks like an error in Radius::StreamServer. Maybe, first there was only ServerHTTP and later on more modules using StreamServer. Please adjust the error message. Best Regards and thanks a lot for RADIATOR! Superb software, perfect service! Charly -- Karl Gaissmaier Kommunikations und Informationszentrum kiz der Universität Ulm Abteilung Infrastruktur SG Netzwerk und Telekommunikation 89069 Ulm Tel.: 49(0)731/50-22499 Fax : 49(0)731/50-1222499 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: (RADIATOR) VSA's (26/3076/x) for the Cisco VPN 3000 Firmware Version 4.x
Hi Hugh, Hugh Irvine schrieb: Hi Charly - Thanks for your mail. The Radiator 3.7.1 standard dictionary already has most of the definitions you list below. I will add the additional ones that you have sent, but they will have the existing Altiga prefix. I'll send you a copy of the modified dictionary in a seperate mail. thanks NB: have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening? I just stumled over this error in the first: Fri Oct 31 09:23:17 2003: ERR: Attribute number 32 (vendor 3076) is not defined in your dictionary Fri Oct 31 09:23:17 2003: DEBUG: Packet dump: *** Received from 134.60.112.177 port 1287 Code: Access-Request ... I can't trigger all missing attributes, since I use not all features of the VPN Concentrator. The most useful info for all new/old attributes is: http://www.cisco.com/en/US/customer/products/hw/vpndevc/ps2284/products_tech_note09186a0080094e96.shtml from where I've the definitions and values, from the other sources I took the mnemonics for the names. Regards Charly -- Karl Gaissmaier KIZ/Infrastructure, University of Ulm, Germany Email:[EMAIL PROTECTED] Service Group Network Tel.: ++49 731 50-22499 === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) VSA's (26/3076/x) for the Cisco VPN 3000 Firmware Version 4.x
Hi Hugh or Mike, after searching for a proper VSA file for the new Version of the Cisco VPN Concentrator software without luck, I assembled a radiator compliant VSA dictionary from the different sources on the web. Hugh or Mike, perhaps you can put it into the goodies folder in the next release/patch. P.S. I know that the standard dictionary contains VSA's for the vendor code 3076 (formerly Altiga), but this is not enough for the new Software Versions on the Cisco VPN Concentrators. Best regards Charly -- Karl Gaissmaier KIZ/Infrastructure, University of Ulm, Germany Email:[EMAIL PROTECTED] Service Group Network Tel.: ++49 731 50-22499 # -- # Start OF Cisco VPN 3k Vendor-specific information # -- # # Accumulated by [EMAIL PROTECTED], 29/10/2003 # Please send me patches and corrections. # # Sources: # Cisco VPN 3000 Concentrator Vendor Specific Attributes 2.0 - 3.6 # on http://www.cisco.com/en/US/customer/products/hw/vpndevc/ps2284/products_tech_note09186a0080094e96.shtml # # and: # cisco3k.dct, Funk Radius Dictionary File for VPN 3000 in the downlaod area # of the Cisco VPN 3000 Concentrator # # and: # http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/csacs4nt/acs31/acsuser/ad.htm#984410 # # # The suffixes at the end of each attribute indicate if the attribute is a # Group only attribute (-G) or is a Group and/or User attribute (-G/U). # # VSA Code 3076, Cisco VPN 3000 Concentrator, formerly Altiga # VENDORATTR 3076 CVPN-3K-Access-Hours-G/U1 string VENDORATTR 3076 CVPN-3K-Simultaneous-Logins-G/U 2 integer VENDORATTR 3076 CVPN-3K-Primary-DNS-G 5 ipaddr VENDORATTR 3076 CVPN-3K-Secondary-DNS-G 6 ipaddr VENDORATTR 3076 CVPN-3K-Primary-WINS-G 7 ipaddr VENDORATTR 3076 CVPN-3K-Secondary-WINS-G8 ipaddr VENDORATTR 3076 CVPN-3K-SEP-Card-Assignment-G/U 9 integer VENDORATTR 3076 CVPN-3K-Tunneling-Protocols-G/U 11 integer VENDORATTR 3076 CVPN-3K-IPSec-Sec-Association-G/U 12 string VENDORATTR 3076 CVPN-3K-IPSec-Authentication-G 13 integer VENDORATTR 3076 CVPN-3K-Arg-ModeCfg-IPSec-Banner15 string VENDORATTR 3076 CVPN-3K-ModeCfg-IPSec-Allow-Passwd-Store-G 16 integer VENDORATTR 3076 CVPN-3K-Use-Client-Address-G/U 17 integer VENDORATTR 3076 CVPN-3k-PPTP-Minimal-Auth-Protocol-G/U 18 integer VENDORATTR 3076 CVPN-3k-L2TP-Minimal-Auth-Protocol-G/U 19 integer VENDORATTR 3076 CVPN-3K-PPTP-Encryption-G 20 integer VENDORATTR 3076 CVPN-3K-L2TP-Encryption-G 21 integer VENDORATTR 3076 CVPN-3k-Arg-Authentication-Server-Type 22 integer VENDORATTR 3076 CVPN-3k-Arg-Authentication-Server-Password 23 string VENDORATTR 3076 CVPN-3k-Arg-Request-Authenticator-Vector24 string VENDORATTR 3076 CVPN-3k-IPSec-LTL-Keepalives25 integer VENDORATTR 3076 CVPN-3k-Arg-IPSec-Group-Name26 integer VENDORATTR 3076 CVPN-3K-Arg-ModeCfg-IPSec-Split-Tunnel-List 27 string VENDORATTR 3076 CVPN-3K-ModeCfg-IPSec-Default-Domain-G 28 string VENDORATTR 3076 CVPN-3K-IPSec-Secondary-Domain-List-G 29 string VENDORATTR 3076 CVPN-3K-IPSec-Tunnel-Type-G 30 integer VENDORATTR 3076 CVPN-3K-IPSec-Mode-Config-G 31 integer VENDORATTR 3076 CVPN-3k-Arg-Authentication-Server-Priority 32 integer VENDORATTR 3076 CVPN-3K-IPSec-User-Group-Lock-G 33 integer VENDORATTR 3076 CVPN-3K-ModeCfg-IPSec-Over-UDP-G34 integer VENDORATTR 3076 CVPN-3K-ModeCfg-IPSec-Over-UDP-Port-Num-G 35 integer VENDORATTR 3076 CVPN-3K-IPSec-Banner2-G 36 string VENDORATTR 3076 CVPN-3K-PPTP-MPPC-Compression-G 37 integer VENDORATTR 3076 CVPN-3K-L2TP-MPPC-Compression-G 38 integer VENDORATTR 3076 CVPN-3K-IP-Compression-G39 integer VENDORATTR 3076 CVPN-3K-IKE-Peer-ID-Check-G 40 integer VENDORATTR 3076 CVPN-3K-IKE-Keepalives-G41 integer VENDORATTR 3076 CVPN-3K-IPSec-Auth-On-Rekey-G 42 integer VENDORATTR 3076 CVPN-3K-Required-FW-Vendor-Code-G 45 integer VENDORATTR 3076 CVPN-3K-Required-FW-Product-Code-G 46 integer VENDORATTR 3076 CVPN-3K-Required-FW-Description-G 47 string VENDORATTR 3076 CVPN-3K-Require-HW-Client-Auth-G48 integer VENDORATTR 3076 CVPN-3K-Require-Individ-User-Auth-G 49 integer VENDORATTR 3076 CVPN-3K-User-Idle-Timeout-G 50 integer VENDORATTR 3076 CVPN-3K-Cisco-IP-Phone-Bypass-G 51 integer VENDORATTR 3076 CVPN-3K-IPSec-Split-Tunnel-Policy-G 55 integer
Re: (RADIATOR) Orinoco AP-500/1000 MAC auth problem
Hello, ... I don't need this Reply Attributes, really. Are you really sure this is needed in your environment? If this is the truth, perhaps we should talk about Firmware versions, but since AP500 V.3.83 it was really not necessary to spend reply attributes here in my environment, just empty Access Accept packets. My AP-500 has V3.95. Since the AP serves more than just one wireless device, it seems reasonable that AP needs to know which MAC address username the RADIUS is granting the access. NAS-IP-address I know for sure is necessary in my case since the AP is behind a firewall, and the AP request (on behalf of the wireless device) is NATed and sent through a router to the RADIUS in another network. The inbound message from the RADIUS to the router certainly has to provide NAS-IP-address information for the router to know which device behind the firewall should pick up (without a broadcast through the entire subnet). First, I'm also running a lot of AP-500 with Firmware v.3.95 and MAC address based authorization, handled by a radius server (radiator) with more than 400 wireless users in the moment, still very fast growing. The AP sends an access-request with the following attributes to the radius server: ### Code: Access-Request Identifier: 134 Authentic: 1641831461358r20628Q9154195169225Y Attributes: NAS-IP-Address = 212.17.1.7 User-Name = 00022d-0eaae0 User-Password = G`173'192242!147:1371750n0182 Code: Access-Accept Identifier: 134 Authentic: 1641831461358r20628Q9154195169225Y Attributes: ### the radius server checks in my configuration just the User-Name, and this is in this context the MAC-addr in the format xx-xx. The password sent by the AP is just the shared secret between the AP and teh radius server, you have no user based passwords without 802.1X. My AP-500 has V3.95. Since the AP serves more than just one wireless device, it seems reasonable that AP needs to know which MAC address The NAS knows already the MAC address, because he sends the Access-Request with the Identifier (e.g.134, see the example above), the Access-Accept has this same Identifier and then the NAS knows the accepted MAC username the RADIUS is granting the access. NAS-IP-address I know for sure is necessary in my case since the AP is behind a firewall, and the AP request (on behalf of the wireless device) is NATed and sent through a router to the RADIUS in another network. The inbound message from the RADIUS to the router certainly has to provide NAS-IP-address information for the router to know which device behind the firewall should pick up (without a broadcast through the entire subnet). do you really believe your NAT Router is able to decode the radius Accept packet, gaining the Radius Attribute NAS-IP-address and then sending this to the proper target. Please tell me the vendor and model of this wonderfull device. No, normally this is done by a state table, IP addrs, protocol and ports so the NAT router knows to where to send the answer packets, I'm quite sure this is also in your environment. Regards Charly P.S. please send us a snippet of your config and your users file for MAC based WLAN authentication -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration Tel.: ++49 731 50-22499 === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Orinoco AP-500/1000 MAC auth problem
Hi Bon, Bon sy schrieb: Sehr geehrter Charly Vielen Dank! Ich bin sehr froh. Mein AP funktioniert. Dass gefaellt mir sehr gut. Das ist mein Log im attachment. Bon P.S. I wish I can write more than this with my limited German proficiency. your german is better than my english :-( ... why do you ask? Where is your problem? I managed to get the RADIATOR to talk to the AP, but the AP initially did not authorize wireless access properly even it receives the access authentication. Apparently (Naturalick) I missed to include in the reply the user-name and NAS-IP-address information. I don't need this Reply Attributes, really. Are you really sure this is needed in your environment? If this is the truth, perhaps we should talk about Firmware versions, but since AP500 V.3.83 it was really not necessary to spend reply attributes here in my environment, just empty Access Accept packets. I am completely surprised by the tech support when they told me they themselves have to get in touch with the AP-1000 developer to get that information. I am hoping someone in the list may have the information handy. what tech support? Compare it to the tech support for radiator ;-) You are right! No tech support gets close to radiator! Yep, thanks to Hugh and Mike and the radiator community! Regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration Tel.: ++49 731 50-22499 === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Bug? changing EUID/EGID with User/Group params doesn't work
Hi Hugh or Mike,
I tried to set the gloabl parameters User and Group to change
the effective ID's for better security. I got the following error
in radiatorlog (trace 4):
Wed Sep 4 14:17:06 2002: NOTICE: SIGHUP received: restarting
Wed Sep 4 14:17:07 2002: DEBUG: Reading group file /etc/group
Wed Sep 4 14:17:07 2002: DEBUG: Reading users file /radiator/etc/test-users
Wed Sep 4 14:17:07 2002: DEBUG: Reading users file /radiator/etc/freeway-users
Wed Sep 4 14:17:07 2002: DEBUG: Reading users file /radiator/etc/ulmathome-users
Wed Sep 4 14:17:07 2002: DEBUG: Reading users file /radiator/etc/wlan-users
Wed Sep 4 14:17:07 2002: ERR: Could not set Group to radiusd: Not owner
Wed Sep 4 14:17:07 2002: INFO: Server started: Radiator 3.3 on mizar
the config file looks like:
AuthPort1812
AcctPort1813
# Set this to the directory where your logfile and details file are to go
LogDir /radiator/log
DbDir /radiator/etc
DefineGlobalVar AcctDir /radiator/accounting
PidFile %D/pidfile
DictionaryFile %D/dictionary.my
User radiusd
Group radiusd
#
undef global Logfile #
#
LogFile
#
define general Logfile #
#
Log FILE
Trace 4
Filename%L/radiatorlog
/Log
#
define Authentication Logfiles #
#
AuthLog FILE
Identifier authlogger
Filename%L/authlog/%{Client:Identifier}-authlog
LogSuccess 1
LogFailure 1
SuccessFormat %q %d.%m.%Y %H:%M:%S %T from %C for %U: OK
FailureFormat %q %d.%m.%Y %H:%M:%S %T from %C for %U: FAIL
/Authlog
the uid and gid for radiusd are defined in /etc/passwd and /etc/group
to 114.
truss delivers the following output. I prefixed the output with line numbers
for better referencing (see below):
- everything works well until line 242, the config file gets read
and the then the different files are openend/read. At line 243 the
seteuid funtion call with uid 114 for user radiusd is called.
243 19527: seteuid(114)= 0
244 19527: getuid()= 0 [114]
245 19527: door_info(4, 0xFFBFF3E0)= 0
246 19527: door_call(4, 0xFFBFF3C8)= 0
247 19527: open(/etc/shadow, O_RDONLY) Err#13 EACCES
248 19527: setgroups(3, 0xFFBFF7B8)Err#1 EPERM
249 19527: setegid(114)Err#1 EPERM
after the seteuid an additional open to /etc/shadow results in EACCES
and the setgroups and setegid function calls results in EPERM.
Perhaps you should call setgroups and setegid first and then
the seteuid?
Anyway, if you read later on again and again /etc/shadow then
you will not be able to change to EUID/EGID less than root.
Please fix the problem with order and document the limitations
in the reference manual, that it will not be possible if someone
uses system /etc/shadow. I just tried it, I didn't know that you
will read this file more than once.
Here comes the whole truss output.
Best regards
Charly
P.S. versions
SunOS mizar 5.9 Generic sun4u sparc SUNW,UltraSPARC-IIi-cEngine
This is perl, v5.6.1 built for sun4-solaris
This is Radiator 3.3 on mizar
--
Karl Gaissmaier Computing Center,University of Ulm,Germany
Email:[EMAIL PROTECTED] Network Administration
Tel.: ++49 731 50-22499
and here comes now really the truss output :-)
1 mizar:...//# truss -f -p 19527
2 19527: poll(0xFFBFF828, 2, 1000) = 0
3 19527: time() = 1031141084
4 19527: time() = 1031141084
5 19527: poll(0xFFBFF828, 2, 1000) (sleeping...)
6 19527: poll(0xFFBFF828, 2, 1000) = 0
7 19527: time() = 1031141085
8 19527: time() = 1031141085
9 19527: poll(0xFFBFF828, 2, 1000) = 0
10 19527: time() = 1031141086
11 19527: time() = 1031141086
12 19527: poll(0xFFBFF828, 2, 1000) = 0
13 19527: time() = 1031141087
14 19527: time() = 1031141087
15 19527: poll(0xFFBFF828, 2, 1000) = 0
16 19527: time() = 1031141088
17 19527: time() = 1031141088
18 19527: poll(0xFFBFF828, 2, 1000
Re: (RADIATOR) Version 3.3 install
Hi Hugh,
Hugh Irvine schrieb:
Hello Charly -
What I usually do is skip the make install step altogether, and just
leave the various versions in seperate directories.
and I do it in the meanwhile with the following startup script:
(tweaking the -I flag on perl startup and dealing with PREFIX=...
and a symbolic link current pointing to actual version)
#!/bin/sh
#
# kg 08/02
#
PERL=/radiator/perl/bin/perl
RADIUS_LIB=/radiator/current/lib/site_perl
RADIUSD=/radiator/current/bin/radiusd
CONFIG=/radiator/etc/radiator-config
PIDFILE=/radiator/etc/pidfile
#
case $1 in
'start')
if [ -f $RADIUSD -a -f $CONFIG ]; then
echo radius (radiator) service starting.
$PERL -I$RADIUS_LIB $RADIUSD -config_file $CONFIG
else
echo $RADIUSD or $CONFIG missing. STOPPED!
fi
;;
'stop')
if [ -f $PIDFILE ]; then
echo Stopping the radius (radiator) service.
kill -15 `cat $PIDFILE`
fi
;;
'restart')
if [ -f $PIDFILE ]; then
echo Restarting the radius (radiator) service.
kill -1 `cat $PIDFILE`
fi
;;
*)
echo Usage: /etc/init.d/radiator { start | stop | restart }
;;
esac
exit 0
I have also a discrete perl installation only for radius, because
I need some modules/versions specific for radius and I will not
pay attention when I upgrade the main perl installation for our
workstations.
Anyway, Hugh and Mike, there are more than one way to solve this
problem with concurrent versions, but I think at least one
solution should be described in the manual or at least in FAQ.
Best regards
Charly
--
Karl Gaissmaier Computing Center,University of Ulm,Germany
Email:[EMAIL PROTECTED] Network Administration
Tel.: ++49 731 50-22499
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Version 3.3 install
Hi Mike,
Mike McCauley schrieb:
Hi Chris,
thanks for reporting this.
Looks like 5.005 does not look in any version independent site files. Looks
like we will have to work on this again.
In the meantime, I have uploaded a new Makefile.PL to the patches area that
removes the use of PREFIX etc, and it now works the same as in earlier
versions:
http://www.open.com.au/radiator/downloads/patches-3.3/Makefile.PL
for me (Solaris 5.9, perl 5.6.1) it's working with this new/old
Makefile.PL as usual with older releases.
Anyway, I think now it's time to rethink the possibility to have
parallel radiator installations simultan for easy upgrade.
(For a lot of us, radiusd is a mission critical application,
upgrades are always a pain if you get running installations
overwritten)
Why do you use the following in your scripts:
# Make sure we get the local libs for preference
BEGIN
{
unshift(@INC, '.');
# You will probably have to uncomment the next line if you want to
# run this script SUID
#$ENV{PATH} = '/sbin:/bin:/usr/sbin:/usr/bin';
}
this helps nothing if you use PREFIX=/new/version/test.
unshift(@INC, '.') is normally wrong. This '.' in @INC is
the CWD of the running process not the installdir of the script.
I think you should do this similar like:
use FindBin;
use lib $FindBin::Bin/../lib/site_perl;
then your PREFIX get's automagically proper handelt.
Perhaps I'm wrong, so please enligth me.
Best regards and thanks again and again and ... for this
wonderful fast and competent support!
Charly
--
Karl Gaissmaier Computing Center,University of Ulm,Germany
Email:[EMAIL PROTECTED] Network Administration
Tel.: ++49 731 50-22499
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Problems with Radiator-3.3 .tgz install (SITEPREFIX)
Hi Hugh or Mike, I install the different radiator version with a PREFIX, so that I can hold more than one version, see below: # cd /radiator/build/Radiator-X.Y.Z # /radiator/perl/bin/perl Makefile.PL PREFIX=/radiator/install-X.Y.Z # make # make test # make install and with a symlink I choose the current version # ln -s /radiator/install-X.Y.Z /radiator/current (of course, I had to adjust the @INC array in the bin/program(s) from: unshift(@INC, '.'); to:unshift(@INC, '/radiator/current/lib/site_perl/5.6.1'); since you did not proper attend this Makefile PREFIX to adjust your @INC Path. I think you could do a: use lib '%%PREFIX%%/lib/site_perl/5.6.1' and clean this MakeMaker Parameter properly in your binaries. Anyway, this was not a problem for me, because I handled this in my way and was still to lazy to post it as a question. But now with version 3.3 you introduced a magic SITEPREFIX Parameter in the Makefile.PL for .rpm but this is still in the .tgz and the PREFIX is no longer used for the lib installment. In my situation, I got the path /lib/perl5/site_perl clobbered because nobody fills this SITEPREFIX with a useful value. If I try a: mizar:.../Radiator-3.3# /radiator/perl/bin/perl Makefile.PL SITEPREFIX=/radiator/install-3.3/ I get: 'SITEPREFIX' is not a known MakeMaker parameter name. Writing Makefile for Radius Where is the solution? Regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration Tel.: ++49 731 50-22499 === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Nomadix VSA's as a contrib
Hi Radiator users, I had the problem that the Noamdix VSA's are hard to find. Here is my knowledge to save the world: # # Nomadix vendor sepecific # VENDORATTR 3309Nomadix-Bw-Up 1 integer VENDORATTR 3309Nomadix-Bw-Down 2 integer VENDORATTR 3309Nomadix-URL-Redirection 3 string VENDORATTR 3309Nomadix-IP-Upsell 4 integer VENDORATTR 3309Nomadix-Acct-Session-Time 5 integer Regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration Tel.: ++49 731 50-22499 === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) User auths if in the users file only?
Hi Chris, chris schrieb: This was where the problem was.thier setup did not follow this standard and was trying to assign 255.255.255.254 as the IP *sigh* This leads me to a questions. I have a mix of nas servers that I need to use on the same radius server. One needs the Framed-IP-Address = 255.255.255.254 attribute and one needs *nothing* sent. what NAS's do you have? Are they not able to configure them with dynamic ip address pools and you specify in the reply items just from which ip pool they shall spent an ip address? See the following axample for my ascends (in the users file): pools-foo Password = ascend, Service-Type = Outbound-User Ascend-IP-Pool-Definition = 1 10.0.0.1 254 ... ... DEFAULT Service-Type = Framed-User, Auth-Type = System Framed-Protocol = MP, Framed-IP-Netmask = 255.255.255.255, Framed-Routing = None, Idle-Timeout = 1800, Session-Timeout = 43200, Ascend-Assign-IP-Pool = 1, Ascend-Source-IP-Check = Source-IP-Check-Yes, Ascend-Link-Compression = Link-Comp-MS-Stac here you see Ascend-Assign-IP-Pool = 1, as defined in the same users file and the Ascend NAS fetches this after reboot or with a special remote config refresh. Anyway, you should spent an Idenifier in the Client Clause like: Client foo.bar.baz Identifier foo Secret mysecret /Client Client yep.bar.baz Identifier yep Secret mysecret /Client and then you can sezup different handlers for the different Clients with different users file: Handler Client-Identifier=foo AuthBy FILE Filenamefoo-users /AuthBy /Handler Handler Client-Identifier=yep AuthBy FILE Filenameyep-users /AuthBy /Handler or you use just one handler and fifferntiate in teh single users file like: DEFAULT Service-Type = Framed-User, Auth-Type = System, Client-Identifier = foo foo reply items DEFAULT Service-Type = Framed-User, Auth-Type = System, Client-Identifier = yep yep reply items Hope this helps Regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Bug: still problems with AuthLDAP2 and TLS
Hi Hugh or Mike,
short: The second time after starting a StartTLS connection against
an OpenLDAP Server the radiusd crashes, the first time after start
it works well.
The radiusd crashes with the following error message:
Can't call method get_context_handle without a package or object reference
at /radiator/perl/lib/site_perl/5.6.1/IO/Socket/SSL.pm line 602.
the config file loooks as following:
Handler Client-Identifier=localhost, Called-Station-Id=DIALIN
AuthBy LDAP2
Hostasdf.xy.uni-ulm.de
Port
Version 3
UseTLS
SSLVerify none
AuthDN cn=foo,ou=bar,ou=baz,dc=uni-ulm,dc=de
AuthPasswordmysecret
NoDefault
BaseDN ou=foo,dc=uni-ulm,dc=de
Scope one
UsernameAttruid
PasswordAttruserpassword
/AuthBy
/Handler
the debug output for the first and second test with radpwtest looks
like:
FIRST CALL, everything okay
*** Received from 134.60.246.8 port 33376
Code: Access-Request
Identifier: 175
Authentic: 1234567890123456
Attributes:
User-Name = foo
Service-Type = Annex-Framed-Tunnel
NAS-IP-Address = 0.0.0.0
NAS-Port = 0
NAS-Port-Type = Async
Framed-IP-Address = 0.0.0.0
User-Password = 1572261931982t12918889160216}x153
Called-Station-Id = DIALIN
Mon Jul 8 08:41:26 2002: DEBUG: Handling request with Handler 'Client-Identifie
r=localhost, Called-Station-Id=DIALIN'
Mon Jul 8 08:41:26 2002: DEBUG: Deleting session for dialin, 0.0.0.0, 0
Mon Jul 8 08:41:26 2002: DEBUG: Handling with Radius::AuthLDAP2:
Mon Jul 8 08:41:26 2002: INFO: Connecting to asdf.xy.uni-ulm.de, port
Mon Jul 8 08:41:26 2002: DEBUG: Starting TLS
Mon Jul 8 08:41:26 2002: INFO: StartTLS negotiated with cipher mode DES-CBC3-SHA
Mon Jul 8 08:41:26 2002: INFO: Attempting to bind with cn=foo,ou=bar
,ou=baz,dc=uni-ulm,dc=de, mysecret (server asdf.xy.uni-ulm.de:)
Mon Jul 8 08:41:26 2002: DEBUG: LDAP got result for cn=foo,ou=bar,dc=uni-ulm,dc=de
Mon Jul 8 08:41:26 2002: DEBUG: LDAP got userPassword: {CRYPT}.
Mon Jul 8 08:41:26 2002: DEBUG: Radius::AuthLDAP2 looks for match with dialin
Mon Jul 8 08:41:26 2002: DEBUG: Radius::AuthLDAP2 ACCEPT:
Mon Jul 8 08:41:26 2002: DEBUG: Access accepted for dialin
Mon Jul 8 08:41:26 2002: DEBUG: Packet dump:
*** Sending to 134.60.246.8 port 33376
Code: Access-Accept
Identifier: 175
Authentic: 1234567890123456
Attributes:
SECOND CALL, SERVER CRASHES
*** Received from 134.60.246.8 port 33377
Code: Access-Request
Identifier: 180
Authentic: 1234567890123456
Attributes:
User-Name = foo
Service-Type = Annex-Framed-Tunnel
NAS-IP-Address = 0.0.0.0
NAS-Port = 0
NAS-Port-Type = Async
Framed-IP-Address = 0.0.0.0
User-Password = 1572261931982t12918889160216}x153
Called-Station-Id = DIALIN
Mon Jul 8 08:41:31 2002: DEBUG: Handling request with Handler 'Client-Identifie
r=localhost, Called-Station-Id=DIALIN'
Mon Jul 8 08:41:31 2002: DEBUG: Deleting session for foo, 0.0.0.0, 0
Mon Jul 8 08:41:31 2002: DEBUG: Handling with Radius::AuthLDAP2:
Mon Jul 8 08:41:31 2002: INFO: Connecting to asdf.xy.uni-ulm.de, port
Mon Jul 8 08:41:31 2002: DEBUG: Starting TLS
here the server crashes
Used versions:
Radiator 3.1 with current patches
Perl 5.6.1
IO::Socket::SSL 0.80
perl-ldap 0.251
SunOS 5.9
Regards
Charly
--
Karl Gaissmaier Computing Center,University of Ulm,Germany
Email:[EMAIL PROTECTED] Network Administration
Tel.: ++49 731 50-22499
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) User auths if in the users file only?
Hi Chris, chris schrieb: I am having the weirdest issue. If I add a user into the users file with the simple line test123 Auth-Type = System They can authenticate and go on thier merry way If the user is not in there and gets caught by the default DEFAULT Auth-Type = System Port-Limit = 2, Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 255.255.255.254, Framed-IP-Netmask = 255.255.255.255, Framed-Routing = None, Idle-Timeout = 1800, Framed-Compression = Van-Jacobson-TCP-IP, Framed-MTU = 1500 They still auth ok(I see the user/pass combo pass the test), but it does weird things that wont let the user complete logon. What *seems* to be happening is that it is not throwing back an IP for the end user. Anyone seen this happen before? I do not want to have to add every user to the users file. Really, you don't have to do this for every user. If it is not a typo in your e-mail then it is in your users file. You MUST have whitespace in front of your Reply Items. Please always turn debug on and send it as partt of the questions. In the debug we could see what reply items are sent back to the NAS. Regards Charly P.S. is this really a working example with this Framed-IP-Address? -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Radiator performance on various platforms.
Hi Brian, Brian Morris schrieb: Hi All, We are looking at upgrading our radiator / radius server and are considering the various platform options available to us. The radiator reference manual cites various performance measurements using versions of hardware and operating systems which are now several generations out of date. Does anyone have any performance information on radiator running on the likes of Solaris 8/9, Redhat 7 or NT 2000 with modern hardware? If so would they like to share their experiences? you should tell us what Authentication schemes you wil be using. I think the performance is only comparable using the same auth schemes. We have radiator running under Solaris 9. Regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) small problem with AuthGeneric.pm and {crypt} schemes
Dear Hugh or Mike,
I've a small problem with AuthGeneric, authentication against OpenLDAP
and {crypt} encrypted passwords.
It seems, that OpenLDAP generates passwords with the slappasswd utility
in the following form:
{CRYPT}
and AuthGeneric compares the crypt scheme identifier against {crypt},
CASE sensitive(see code snippet from AuthGeneric.pm):
elsif ($pw =~ /^{crypt}(.*)/)
{
# Its a UNIX crypted password
$result = (crypt($submitted_pw, $1) eq $1);
}
and AuthLDAP2 delivers the following userPassword from the OpenLDAP
Server (sure it's stored in this format):
Mon Jul 1 14:55:56 2002: DEBUG: LDAP got userPassword: {CRYPT}iRe5XZ5WN5FI.
Mon Jul 1 14:55:56 2002: DEBUG: Radius::AuthLDAP2 looks for match with
user-xy
Mon Jul 1 14:55:56 2002: DEBUG: Radius::AuthLDAP2 REJECT: Bad Password
Mon Jul 1 14:55:56 2002: INFO: Access rejected for user-xy: Bad Password
Request: Could you please check against the different crypt schemes in
a case insensitiv manner as a patch and in the next release?
elsif ($pw =~ /^{crypt}(.*)/i)
{
# Its a UNIX crypted password
$result = (crypt($submitted_pw, $1) eq $1);
}
Used Versions:
radiator 3.1 with latest patches installed
perl 5.6.1
SunOS 5.9
Regards
Charly
--
Karl Gaissmaier Computing Center,University of Ulm,Germany
Email:[EMAIL PROTECTED] Network Administration
Tel.: ++49 731 50-22499
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) evaluating comparing Steel-Belted Radius
Hi Dave, here you get an independent customer view. We are using Radiator since 2 years for dialin, wlan authentication, etc. Radiator is so flexible that you are on a secure path for the future. Mike McCauley schrieb: Hi Dave, here is a very brief product diff you may want to use. We are preparing a point-by-point diff now. We think that Radiator is better than Funk for these reasons: 1. Runs on a _much_ wider range of hardware and operating systems 2. Full source provided therefore more bugs are fixed by customers, this is important! 3. Much more flexible (you can combine and chain authentication methods to solve very unusual authentication requirements, as well as all the common ones) The most flexible Radius Daemon I've ever dealed with. 4. Authenticates from a much wider range of user databases. Works with almost any SQL database schema on any SQL database, not just the one provided by the vendor. 5. Much less expensive a really fair price 6. More reliable very stable 7. Better support the best choice between Open Source and Commercial. I've no other software running with this support quality and short response time. You hear it, I like this piece of software. Regards K. Gaissmaier === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) SNMPAgent patch: access restrictions now available
Hi all and Mike, I wrote a patch to SNMPAgent to restrict the acces to the Radius SNMP vars, especially to disallow unauthorized resets. You can now spend two separate communities for read-only and read-write and you can define a Managers list for allowed hosts. I would appreciate if the community decides this stuff useful. Please raise your hands if yes so Mike gets perhaps convinced to add this to one of the next patches/releases. I wrote this backward compatible to old config files with Community defined. If you don't define a managers list all hosts has access. The following parameters are new to the SNMPAgent clause: - 6.13.3 Community deprecated but allowed for backward compatibility 6.13.5 ROCommunity SNMP V1 provides a weak method of authenticating SNMP requests, using the "community name". This optional parameter allows you to specify the SNMP V1 community name that will be honored by SNMPAgent for read-only access. Defaults to nothing, you have to define one by yourself. We strongly recommend that you choose a community name and keep it secret. # Use a secret community. ROCommunity mysnmprosecret 6.13.6 RWCommunity This optional parameter allows you to specify the SNMP V1 community name that will be honored by SNMPAgent for read-write access. Knowing this secret you are able to reset Radiator via SNMP. Defaults to nothing. If you don't need resetting via SNMP use only ROCommunity. # only necessary for resetting via SNMP RWCommunity extremelysecure 6.13.7 Managers This optional parameter specifies a list of SNMP managers that have access to SNMPAgent. The value is a list of host names or addresses, separated by white space or comma. You can have any number of Managers lines. Defaults to nothing with all hosts allowed. # allowed SNMP managers Managersfoo.bar.edu 192.168.1.11, noc.rz.uni-ulm.de Managersbaz.bar.com,10.1.1.254 TODO: Documentation should be rewritten by a native speaker :-( Have fun with it. Regards Charly Gaissmaier SNMPAgent.pm.gz
Re: (RADIATOR) radiator cgi script hosting
Jay West schrieb: There's a cgi program included in radiator that can be called from a webbrowser to see who's currently online, etc. etc. Is there any way that this cgi can be run on a different machine than the radiator server? I hate mucking up my nice radius servers with web server software when I have quite a few perfectly good web servers sitting next to them. Is this possible and what (in general terms) is required? Thanks in advance!! Jay West I had the same problem. You have more than one choice: 1.) share the filesystem via nfs between your radius server host and your web server host 2.) use a database as backend to radiator 3.) forward all radius ACCOUNTING records with AuthBy Radius to a second radius server. You have to adjust the AuthByPolicy and the NoForwardAuthentication to get what you want. Read the doku with this hints carefully and afterwards contact me again if there are still problems. 4.) Nr. 3 was my first solution but with Ascend as the NAS you have a nice feature called "Call Logging" and this is just a second path to radius accounting. I configured my Ascend Box as usual for radius authentication and accounting with my radiusd hosts and additionally Call Logging to my web host with an additional radiator as accounting server running. Thats all and works fine for me. Regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration Tel/Fax: ++49 731 50 22499/22471 pgp-key available: http://www.uni-ulm.de/urz/Netzwerk/uuca/keylist.html === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Radiator 2.14 how compressed?
Hi all, was anyone successful with downloading and decompression of the Radiator-2-14.tgz? I got: # /soft/local/gnu/bin/tar ztf Radiator-2-14.tgz gzip: stdin: invalid compressed data--format violated /soft/local/gnu/bin/tar: Child returned status 1 /soft/local/gnu/bin/tar: Error exit delayed from previous errors Something wrong with the package I think. Regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration Tel/Fax: ++49 731 50 22499/22471 pgp-key available: http://www.uni-ulm.de/urz/Netzwerk/uuca/keylist.html === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Caller-Station-Id
Hello, "Requiem Aurelien (Ext/NTC)" schrieb: Hello Is there a way to specify the caller-station-id with radpwtst ? Thanks a lot ! try this: # ./radpwtst -? Unknown option: ? usage: ./radpwtst [-time] [-iterations n] [-trace] [-s server] [-secret secret] [-noauth] [-noacct][-nostart] [-nostop] [-status] [-chap] [-accton] [-acctoff] [-framed_ip_address address] [-auth_port port] [-acct_port port] [-identifier n] [-user username] [-password password] [-nas_ip_address address] [-nas_port port] [-nas_port_type type] [-service_type service] [-session_id string] [-delay_time n] [-session_time n] [-input_octets n] [-output_octets n] [-timeout n] [-dictionary file] [-gui] [attribute=value]... if you have the last line option [attribute=value] then you can specify any attribute from the dictionary. If you don't see this option, fetch the newest radpwtst from the patches directory. Regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration Tel/Fax: ++49 731 50 22499/22471 pgp-key available: http://www.uni-ulm.de/urz/Netzwerk/uuca/keylist.html === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SNMP Counter logging
Hi Leigh and Mike, Mike McCauley schrieb: Hi Leigh, ... 5. I have forwarded your message to a chap who I know has some _excellent_ SNMP monitoring-mysql software with a web interface. Its about 3000 times better than MRTG, highly configurable, with beautiful graphs, but I dont know if its on offer to anyone. You may hear from him. it would be nice to tell the list what you get as answer from this guy because I'm also loooking in the moment for such a program. Regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration Tel/Fax: ++49 731 50 22499/22471 pgp-key available: http://www.uni-ulm.de/urz/Netzwerk/uuca/keylist.html === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Still problems with internal session database: MaxSessions exceeded
Hi all, I've still problems with the internal session database, see the sections in my simple config: Client ulmathome.rz.uni-ulm.de Secret nottotell NasType ascend /Client # NasType is an Ascend MAX TNT, no FingerProg specified # but finger to the MAX is allowed if radiator will use an internal # finger subroutine (noboby knows the algorithm when radiator is # ross checking his internal session database with the real state) AuthBy UNIX Identifier UnixPwd Filename/etc/shadow GroupFilename /etc/group /AuthBy Handler NAS-IP-Address=X.Y.A.B AcctLogFileName %L/%C/detail # here is the limitation to 2 concurrent sessions MaxSessions 2 AuthBy FILE Filename%D/users-file /AuthBy /Handler I installed the patches downloaded at 24. June. Symptoms: Some users can't dial in because radiator erronously decides that the maxsessions are exceeded even if you can check with finger that this user isn't online. See the fragment of my trace file, trace level 3: Jul 1 12:14:19 1999: INFO: Access rejected for usera: MaxSessions exceeded Jul 1 12:14:34 1999: INFO: Access rejected for usera: MaxSessions exceeded Jul 1 12:14:53 1999: INFO: Access rejected for usera: MaxSessions exceeded Jul 1 12:16:07 1999: INFO: Access rejected for usera: MaxSessions exceeded Jul 1 12:16:37 1999: INFO: Access rejected for usera: MaxSessions exceeded Jul 1 12:16:49 1999: INFO: Access rejected for usera: MaxSessions exceeded Any help welcome. Questions: How does radiator validate his internal session database with the reality? How can I trigger radiator to show me his internal session database? Regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration Tel/Fax: ++49 731 50 22499/22471 pgp-key available: http://www.uni-ulm.de/urz/Netzwerk/uuca/keylist.html === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) SNMP and additional access restrictions on IP layer
Hi all, is there a possibility to restrict the snmp access to some noc stations by IP address, similar to the client clause: SNMPAgent xx.yy.zz.aa ReadCommunity notsosecret WriteCommunity handleitsafely /SNMPAgent or the default clause for all other noc stations SNMPAgent ReadCommunity public # WriteCommunity by default not enabled /SNMPAgent anything else is to dangerous! Regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration Tel/Fax: ++49 731 50 22499/22471 pgp-key available: http://www.uni-ulm.de/urz/Netzwerk/uuca/keylist.html === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Ascend ISDN Auth problem
Hi Mike, Mike McCauley schrieb: Hi Karl, Actually, the order of the entries in the users file does not effect the search order, so I think it should be getting to "jimmy" when jimmy logs in. Uups, then is this a different behavior to other radius Daemon's, I think. As I remember, the DEFAULT entry has always to be the last entry in the ascend radiusd. Regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration Tel/Fax: ++49 731 50 22499/22471 pgp-key available: http://www.uni-ulm.de/urz/Netzwerk/uuca/keylist.html === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Keeping lines open
Hi, ryanm schrieb: Has anyone implemented a way to keep 2/4/6 phone lines open by booting the user who has been logged on the longest?? Where we have 200 modems in a pool the ppl that have been on the longest are usually the ppl who are trying to stay on 24/7. We want to keep 2-4 phone lines open so a user will never get a busy signal. Also does anyone know if it is possible to disconnect users who are pinging servers to stay online?? I want to boot users who are not doing anything for hours on end trying to stay connected or whatever. It depends on the NAS Box. With Ascend you can do this. What box do you have? Regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration Tel/Fax: ++49 731 50 22499/22471 pgp-key available: http://www.uni-ulm.de/urz/Netzwerk/uuca/keylist.html === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) radwho.cgi and autmatically reloading currect status
Hi Mike, if you insert the META Tag HTTP-EQUIV=Refresh in the head clause, then we get an automatic reload of the current dialin-users (al least with Netscape and IE browsers). It would be nice, if this would be configurable (time/s as a parameter, or no automatic reload). See the following HTML snippet: html head titleCurrent Sessions by $sortBy/title META HTTP-EQUIV="Refresh" CONTENT=30 /head And if you'll code this for us, it would be nice to show the time of the actualisation in the title, e.g. Current Sessions by User-Name, fetched at Mon May 3 15:46:20 regards Charly === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Give a dinamic IP from a pool
Hi Fernando, Fernando Martin wrote: Hi Mike, Thank you. Now my radiator 2.13.1 is working. I have several questions about the progress to give a dinamic IP: 1- If I configure this users file fer User-Password = "fer" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 255.255.255.254, - why do you wish to configure this invalid IP address Framed-IP-Netmask = 255.255.255.255, Framed-Routing = None, Framed-MTU = 1500, Framed-Compression = Van-Jacobson-TCP-IP Then fer get an IP from the NAS server ( My NAS has a pool defined) Is it right? Some times it works but others does not. Why? This is not the poper way, see below 2- If I use: fer User-Password = "fer" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Netmask = 255.255.255.255, Framed-Routing = None, Framed-MTU = 1500, Framed-Compression = Van-Jacobson-TCP-IP And use FramedGroupBaseAddress 193.146.120.120. Then fer get an IP But not 120 + Port . I think this is a problem with my NAS. It has two PRIs If I do not use # FramedGroupBaseAddress 193.146.120.120.the system get me an IP but I do not know how, I think the NAS.. 3- FinallyI think the best solution to my problems is that I want to give a dinamic IP from a pool defined on the Radiator configuration. How to do that? How and where to define a pool? and how to configure the users profile to get it? Could I define several pools? You do this with pseudo user entries, and this is different for the special NAS. see this example for a Ascend NAS: #- snipp - pools-nasname Password = "ascend", Service-Type = Outbound-User Ascend-IP-Pool-Definition = "1 172.16.1.1 240" #- # DEFAULT Auth-Type = System Framed-Protocol = PPP, Framed-IP-Netmask = 255.255.255.255, Framed-Routing = None, Ascend-Assign-IP-Pool = 1 #-- #- snipp - Annotation: pools-nasname: nasname must be replaced by the system name of your nas. Turn the trace level in the radiator.cfg to 4 und look for what pools-xx your NAS is asking after a reset or refresh of the remote config. The line Ascend-IP-Pool-Definition = "1 172.16.1.1 240" is again Vendor specific (see your dictionary) and mens in this example: Poll Number 1, Base Address 172.16.1.1, and 240 IP Addresses starting from 172.16.1.1 to 172.16.1.240 The DEFAULT entry has the reply item with: Ascend-Assign-IP-Pool = 1 1 means her, give the user a number of IP-Pool number 1. If you need more pools, the pseudo entry would look like the following 3 lines, ans so on ansd so on: (the first line last line has no comma at the end!) (the whitespace in klines after the first line are important) pools-nasname Password = "ascend", Service-Type = Outbound-User Ascend-IP-Pool-Definition = "1 172.16.1.1 240", Ascend-IP-Pool-Definition = "2 172.16.10.100 15" Look in your vendor dokumentation. regards Charly === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) beginners question
Hi Arnie, Arnie Roberts wrote: Hi, I would like to have a set of default reply items for most of my users (provided they authenticate OK) and a few exceptions who get reply items specific to them. What differentiates the default users from the 'specials' is their usernames and passwords and nothing else - i.e. they all authenticate via the same NAS, and it will always supply the same attributes in the request (except the username and password). The example user file says # DEFAULT users will be checked in the order they appear in this # file. They # will be checked in order until one is found that matches and # which does not contain Fall-Through and also has entries like this - DEFAULT Service-Type = Administrative-User, Auth-Type = System Idle-Timeout = 2000, But what is a DEFAULT user? A DEFAULT user is a user without an special Username entry Is the Service-Type attribute here a request item which is checked? Yes, of course, all items in the first line of a entry are check-items, all following lines are reply items. Do this in the following way: special-one Password = mysecret-one special-one-reply-item-1 = 1, special-one-reply-item-2 = 2, special-one-reply-item-3 = 3, special-one-reply-item-4 = 4 special-two Password = mysecret-two special-two-reply-item-1 = 1, special-two-reply-item-2 = 2, special-two-reply-item-3 = 3 DEFAULT Auth-Type = System default-reply-item-1 =1, default-reply-item-2 =2, default-reply-item-3 =3, default-reply-item-4 =4, default-reply-item-5 =5 This means, User with names special-one and special-two get differently handled as all other users. And because you have perhaps a lot of other users, you will not list all usernames and passwords in the users-file, you use the System passwd files. That's the trick with the DEFAULT regards Charly === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) BUG: After SIGHUP radiator doesn't proper reread the config file
Hi, when I change the config file from Realm ... ... \Realm to Handler NAS-IP-Address=X.X.X.X ... ... \Handler Handler NAS-IP-Address=Y.Y.Y.Y ... ... \Handler and send a SIGHUP to the radiator, he is still trying to handle the requests with the Realm 'Realm=', even if there is no longer ANY Realm Clause in the config. See the trace Output after SIGHUP: ue Apr 27 10:59:01 1999: NOTICE: SIGHUP received: restarting Tue Apr 27 10:59:01 1999: DEBUG: Reading password file /etc/shadow Tue Apr 27 10:59:04 1999: DEBUG: Reading group file /etc/group Tue Apr 27 10:59:04 1999: DEBUG: Reading users file /usr/local/radiator/raddb/freeway-users Tue Apr 27 10:59:04 1999: DEBUG: Reading users file /usr/local/radiator/raddb/ulmathome-users Tue Apr 27 10:59:04 1999: INFO: Server started Tue Apr 27 10:59:09 1999: DEBUG: Handling request with Handler 'Realm=' ^ here is the problem, because I have no longer any Realm Clause in the config file. If I kill the radiator and restart it, radiator works okay, see the trace output(see SIGTERM in difference to SIGHUP!): Tue Apr 27 10:59:25 1999: NOTICE: SIGTERM received: stopping Tue Apr 27 10:59:29 1999: DEBUG: Reading password file /etc/shadow Tue Apr 27 10:59:32 1999: DEBUG: Reading group file /etc/group Tue Apr 27 10:59:32 1999: DEBUG: Reading users file /usr/local/radiator/raddb/freeway-users Tue Apr 27 10:59:32 1999: DEBUG: Reading users file /usr/local/radiator/raddb/ulmathome-users Tue Apr 27 10:59:33 1999: INFO: Server started Tue Apr 27 10:59:33 1999: DEBUG: Check if Handler NAS-IP-Address=X.X.X.X should be used to handle this request Tue Apr 27 10:59:33 1999: DEBUG: Check if Handler NAS-IP-Address=Y.Y.Y.Y should be used to handle this request Tue Apr 27 10:59:33 1999: DEBUG: Handling request with Handler 'NAS-IP-Address=Y.Y.Y.Y' Version 2.13.1, Patches applied. OS=Solaris 2.6 Perl-Version: 5.005_03 built for sun4-solaris regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration Tel/Fax: ++49 731 50 22499/22471 pgp-key available: http://www.uni-ulm.de/urz/Netzwerk/uuca/keylist.html === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
