(RADIATOR) Catching User's Passwords
Hi,
I have configured a pre_auth hook and am trying to capture all customers
passwords. (I.E.)
sub {
my $type = ${$_[0]}-get_attr('Acct-Status-Type');
if ($type eq 'Start') {
my $debug_username = ${$_[0]}-get_attr('User-Name');
my $debug_pwd = ${$_[0]}-get_attr('User-Password');
my $debug_called =
${$_[0]}-get_attr('Called-Station-Id');
my $debug_calling =
${$_[0]}-get_attr('Calling-Station-Id');
my $debug_NASIP = ${$_[0]}-get_attr('NAS-IP-Address');
my $debug_NASPort = ${$_[0]}-get_attr('NAS-Port');
my $debug_sessionid =
${$_[0]}-get_attr('Acct-Session-Id');
my $debug_framedip =
${$_[0]}-get_attr('Framed-IP-Address');
main::log($main::LOG_INFO, LOG: ACCT: ${type}:
$debug_username || $debug_pwd || $debug_c
alled || $debug_NASIP || $debug_NASPort || $debug_sessionid ||
$debug_calling || $debug_framedip);
}
---
This is what is captured:
Wed Sep 12 16:53:21 2001: INFO: LOG: ACCT: Start: [EMAIL PROTECTED] ||
|| 85520100 || 210.215.0.74 || 116 || 6A94 || || 210.215.30.64
For some reason the Password os not being retrieved. Can any one shed
some light on why or another
way to get the password in Clear Text
Access Request:
--
Code: Access-Request
Identifier: 123
Authentic:
151168246243172218207108224Kuw216133243[
Attributes:
User-Name = [EMAIL PROTECTED]
User-Password =
232p174231128!160s206!207%9!16117
NAS-IP-Address = 172.16.0.1
--
Thanks,
Paul
===
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) Catching User's Passwords
solong. Levent Paul Thorton wrote: Hi, I have configured a pre_auth hook and am trying to capture all customers passwords. (I.E.) do you want to get the user pass? if so why don you avtivate pw.log in radiator? solong.Levent === 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) Framed-IP of 0.0.0.0
Hello everyone, We're using 2.18.2. Recently we started to see FRAMEDIPADDRESS of 0.0.0.0 in RADONLINE. These records create a problem when checking for Simultaneous-Use. Is this a problem with the Ascend NASes that we use? Thanks in advance, William === 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) Framed-IP of 0.0.0.0
Yes. I have seen this before prior to using Radiator in some of my NASes. We also have some Ascends. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of William Hernandez Sent: Wednesday, September 12, 2001 07:16 To: Radiator Subject: (RADIATOR) Framed-IP of 0.0.0.0 Hello everyone, We're using 2.18.2. Recently we started to see FRAMEDIPADDRESS of 0.0.0.0 in RADONLINE. These records create a problem when checking for Simultaneous-Use. Is this a problem with the Ascend NASes that we use? Thanks in advance, William === 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. === 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) Framed-IP of 0.0.0.0
I got this when someone connect in ISDN at two channels, the second record is showing this IP. Ascend Max TNT Hello everyone, We're using 2.18.2. Recently we started to see FRAMEDIPADDRESS of 0.0.0.0 in RADONLINE. These records create a problem when checking for Simultaneous-Use. Is this a problem with the Ascend NASes that we use? === 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) Framed-IP of 0.0.0.0
Exactly true for us as well, except that the NASes were Ciscos (5300s, I think). When we were using USR/3Com gear, we didn't have this problem :-\ Dave -Original Message- From: Pascal Robert [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 12, 2001 12:02 PM To: William Hernandez; Radiator Subject: Re: (RADIATOR) Framed-IP of 0.0.0.0 I got this when someone connect in ISDN at two channels, the second record is showing this IP. Ascend Max TNT Hello everyone, We're using 2.18.2. Recently we started to see FRAMEDIPADDRESS of 0.0.0.0 in RADONLINE. These records create a problem when checking for Simultaneous-Use. Is this a problem with the Ascend NASes that we use? === 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. === 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)
Title: unsubscribe
Re: (RADIATOR) Catching User's Passwords
Hello Paul -
As you can see from the trace, the User-Password is not in clear text anyway
(it is MD5 encrypted with the shared secret).
You can use the special character %P to get the decrypted string, or as
Levent has mentioned, you can just use the password log.
regards
Hugh
On Wednesday 12 September 2001 16:58, Paul Thorton wrote:
Hi,
I have configured a pre_auth hook and am trying to capture all customers
passwords. (I.E.)
sub {
my $type = ${$_[0]}-get_attr('Acct-Status-Type');
if ($type eq 'Start') {
my $debug_username = ${$_[0]}-get_attr('User-Name');
my $debug_pwd = ${$_[0]}-get_attr('User-Password');
my $debug_called =
${$_[0]}-get_attr('Called-Station-Id');
my $debug_calling =
${$_[0]}-get_attr('Calling-Station-Id');
my $debug_NASIP = ${$_[0]}-get_attr('NAS-IP-Address');
my $debug_NASPort = ${$_[0]}-get_attr('NAS-Port');
my $debug_sessionid =
${$_[0]}-get_attr('Acct-Session-Id');
my $debug_framedip =
${$_[0]}-get_attr('Framed-IP-Address');
main::log($main::LOG_INFO, LOG: ACCT: ${type}:
$debug_username || $debug_pwd || $debug_c
alled || $debug_NASIP || $debug_NASPort || $debug_sessionid ||
$debug_calling || $debug_framedip);
}
---
This is what is captured:
Wed Sep 12 16:53:21 2001: INFO: LOG: ACCT: Start: [EMAIL PROTECTED] ||
|| 85520100 || 210.215.0.74 || 116 || 6A94 || || 210.215.30.64
For some reason the Password os not being retrieved. Can any one shed
some light on why or another
way to get the password in Clear Text
Access Request:
--
Code: Access-Request
Identifier: 123
Authentic:
151168246243172218207108224Kuw216133243[
Attributes:
User-Name = [EMAIL PROTECTED]
User-Password =
232p174231128!160s206!207%9!16117
NAS-IP-Address = 172.16.0.1
--
Thanks,
Paul
===
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: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
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) Framed-IP of 0.0.0.0
Hello William - The only way to understand what is happening is to look at a trace 4 debug from Radiator to see in what circumstances this occurs. As it is the NAS that sends the accounting packets that are used to maintain the session database, it is highly likely that this is a NAS issue. Note that we have seen similar behaviour occassionally when it is Radiator allocating the addresses, and one work-around is to send a copy of the address in a Class attribute and use a PreClientHook to restore it. Obviously if it is the NAS that is allocating the addresses, you will need to check with the NAS vendor if there is a fix for the problem. regards Hugh On Thursday 13 September 2001 00:16, William Hernandez wrote: Hello everyone, We're using 2.18.2. Recently we started to see FRAMEDIPADDRESS of 0.0.0.0 in RADONLINE. These records create a problem when checking for Simultaneous-Use. Is this a problem with the Ascend NASes that we use? Thanks in advance, William === 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: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === 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)
unsubscribe === 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) AuthUNIX/FILE Authentication and realms.
Is it possible to get Radiator to authenticate based on username only, even if the username is rewritten to include the realm? (it is required that we rewrite to include the realm as our radius supports over 8 different providers and we need to be able to account for them all based on username@realm, we also use Called-Station-Id to map to some realms) All other realms are working fine as they authenticate from a custom built authentication module which looks after this, however the below needs to be authenticated in the following manner. I need to be able to authenticate based on the username portion only (for the AuthUNIX/FILE), but to use the rewritten realm for accounting and session database entries. Ideas? What am I missing? If I add RewriteUsername s/^([^@]+).*/$1/ immediately after the Authby GROUP, then authentication works. UsernameMatchesWithoutRealm doesn't seem to work. I've also tried writing seperate handlers for Authentication and Accounting, but the problem then arises, that I can't manage the session database (SQL) correctly with the realms. Handler Realm=SOUTHWEST.COM.AU RewriteUsername tr/A-Za-z0-9_@\.-//cd RewriteUsername s/^([^@]+).*/$1/ RewriteUsername s/^(.*)/$1\@southwest.com.au/ RewriteUsername s/^([^@]+)(.*)/lc($1).uc($2)/e AuthBy GROUP UsernameMatchesWithoutRealm AuthByPolicy ContinueWhileAccept AuthBy FILE UsernameMatchesWithoutRealm Filename %D/users RejectEmptyPassword /AuthBy AuthBy UNIX UsernameMatchesWithoutRealm Identifier Unix Filename /etc/passwd GroupFilename /etc/group RejectEmptyPassword /AuthBy /AuthBy PostAuthHook file:/etc/radiusd/radius.call AcctLogFileName /var/adm/radacct/%C/detail AccountingHandled /Handler === 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) Splitting Auth and Accounting
Hi, I have been reading the Mailing list archives in an attempt to find out how to split the Authentication and Accounting up, in order to authenticate from a flat file, but send the accounting packet to another radius server (Proxy it) I have seen one example of this, but it was not very clear. Can you please help. I was thinking, something like this might work? Handler Realm=realm.net AcctLogFileName /var/log/radacct/detail PreAuthHook file:/usr/local/etc/preauthhook.pl AuthByPolicy DoAllAuths AuthBy FILE Filename %D/auth_file /AuthBy AuthBy RADIUS Host 1.1.1.1 Secretblahblah # AuthPort 1812 # Commented out as only want to send account AcctPort 1813 ReplyHook file:/usr/local/etc/replyhook.pl /AuthBy /Handler I am guessing if the AuthBy File fails, it will reject the user completely and not send the accounting packet? If this is the right way to do it? I basically do not want the radius server to know about it unless it authenticates of the flat file correctly. Cheers, Paul Thornton. === 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.
