(RADIATOR) Problem with rewriteusername and chap
Dear all, First, I must say sorry for the log post (and html). Secondly, we have a client sending: username = [EMAIL PROTECTED] via MS-CAHP V2 and the password "password". We are running a simple config.file: RewriteUsername s/[EMAIL PROTECTED]// Client DEFAULT Secret mysecret DupInterval 0 /Client Realm DEFAULT AuthBy FILE Filename /usr/local/etc/users /AuthBy /Realm the users file contains: user User-Password="password", user2 User-Password="password", But the following happens: Yeilds: Wed Jan 7 17:54:21 2004: DEBUG: Reading users file /usr/local/etc/users Wed Jan 7 17:54:21 2004: DEBUG: Finished reading configuration file '/usr/local/etc/simple.cfg' Wed Jan 7 17:54:21 2004: DEBUG: Reading dictionary file '/var/log/radius/dictionary' Wed Jan 7 17:54:21 2004: DEBUG: Creating authentication port 0.0.0.0:1813 Wed Jan 7 17:54:21 2004: DEBUG: Creating accounting port 0.0.0.0:1812 Wed Jan 7 17:54:21 2004: NOTICE: Server started: Radiator 3.8 on dns1 Wed Jan 7 17:54:25 2004: DEBUG: Packet dump: *** Received from 172.16.1.52 port 1814 Code: Access-Request Identifier: 13 Authentic: /s0126143149200R154239244tu_138 Attributes: MS-CHAP-Challenge = "o167k193136128203138262141602301270K" MS-CHAP2-Response = "10145228250/r177"E13148236%25182230Y-1470246129b1815318832021781931654143@249s28X1652162" User-Name = "[EMAIL PROTECTED]" NAS-IP-Address = 172.16.1.52 NAS-Identifier = "[EMAIL PROTECTED]/24" Service-Type = Framed-User Framed-Protocol = PPP Proxy-State = 208 Wed Jan 7 17:54:25 2004: DEBUG: Rewrote user name to user Wed Jan 7 17:54:25 2004: DEBUG: Handling request with Handler 'Realm=DEFAULT' Wed Jan 7 17:54:25 2004: DEBUG: Deleting session for [EMAIL PROTECTED], 172.16.1.52, Wed Jan 7 17:54:25 2004: DEBUG: Handling with Radius::AuthFILE: Wed Jan 7 17:54:25 2004: DEBUG: Radius::AuthFILE looks for match with user2 Wed Jan 7 17:54:25 2004: DEBUG: Radius::AuthFILE REJECT: Bad Password Wed Jan 7 17:54:25 2004: INFO: Access rejected for user: Bad Password Wed Jan 7 17:54:25 2004: DEBUG: Packet dump: *** Sending to 172.16.1.52 port 1814 Code: Access-Reject Identifier: 13 Authentic: /s0126143149200R154239244tu_138 Attributes: Reply-Message = "Request Denied" Proxy-State = 208 But if the follwoing is used: radpwtst -user [EMAIL PROTECTED] -password password the output below: *** Received from 127.0.0.1 port 60973 Code: Access-Request Identifier: 215 Authentic: 1234567890123456 Attributes: User-Name = "[EMAIL PROTECTED]" Service-Type = Framed-User NAS-IP-Address = 203.63.154.1 NAS-Port = 1234 Called-Station-Id = "123456789" Calling-Station-Id = "987654321" NAS-Port-Type = Async User-Password = "137234,163v14618889160216}x153" Wed Jan 7 18:05:05 2004: DEBUG: Rewrote user name to user2 Wed Jan 7 18:05:05 2004: DEBUG: Handling request with Handler 'Realm=DEFAULT' Wed Jan 7 18:05:05 2004: DEBUG: Deleting session for [EMAIL PROTECTED], 203.63.154.1, 1234 Wed Jan 7 18:05:05 2004: DEBUG: Handling with Radius::AuthFILE: Wed Jan 7 18:05:05 2004: DEBUG: Radius::AuthFILE looks for match with user2 Wed Jan 7 18:05:05 2004: DEBUG: Radius::AuthFILE ACCEPT: Wed Jan 7 18:05:05 2004: DEBUG: Access accepted for user2 Wed Jan 7 18:05:05 2004: DEBUG: Packet dump: *** Sending to 127.0.0.1 port 60973 Code: Access-Accept Identifier: 215 Authentic: 1234567890123456 Attributes: BUT With rewriteUsername OFF and using MS-CHAP V2, and chaging the user anmes in the users file to [EMAIL PROTECTED] It works. *** Received from 172.16.1.52 port 1814 Code: Access-Request Identifier: 14 Authentic: 20227JyPz8192168183245M252k139j Attributes: MS-CHAP-Challenge = "14l15825209199205a8J137u402146" MS-CHAP2-Response = "10F195ps4160|2502001763q213c2442175224269j180"2203238?157230231206184*192K194203y30" User-Name = "[EMAIL PROTECTED]" NAS-IP-Address = 172.16.1.52 NAS-Identifier = "[EMAIL PROTECTED]/24" Service-Type = Framed-User Framed-Protocol = PPP Proxy-State = 80 Wed Jan 7 18:08:21 2004: DEBUG: Handling request with Handler 'Realm=DEFAULT' Wed Jan 7 18:08:21 2004: DEBUG: Deleting session for [EMAIL PROTECTED], 172.16.1.52, Wed Jan 7 18:08:21 2004: DEBUG: Handling with Radius::AuthFILE: Wed Jan 7 18:08:21 2004: DEBUG: Radius::AuthFILE looks for match with [EMAIL PROTECTED] Wed Jan 7 18:08:21 2004: DEBUG: Radius::AuthFILE ACCEPT: Wed Jan 7 18:08:21 2004: DEBUG: Access accepted for [EMAIL PROTECTED] Wed Jan 7 18:08:21 2004: DEBUG: Packet dump: Does anybody have any idea's where we would be going wrong? regards Chris. -- Chris Simmons Network Engineer St Georges Hospital Medical School Tel: 020 8725 0234 mail: [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: (RADIATOR) Time Restriction
Hugh,List
I got it working,
My data types were incorrect,
here is what happened...
I had my Time attribute datatype set at 1 (integer), which means in my
RadConfigs tables for my customers it was looking at the integer value (an
integer field) which had the value of 2. So i change the data type to 2
(string i think) and it allowed me to log on. I also changed the
Session-Timeout attribute to a string as well, so until Time would work...
Everything works sweet now!!
Have a good day guys...
Kind Regards Nathan Franklin TSN Internet [EMAIL PROTECTED] MSN:
[EMAIL PROTECTED] 'Great managers meet deadlines and make money.
Great leaders meet the challenge and make history.'
- Original Message -
From: Hugh Irvine [EMAIL PROTECTED]
To: Nathan 'Franko' Franklin [EMAIL PROTECTED]
Sent: Wednesday, January 07, 2004 6:38 PM
Subject: Re: (RADIATOR) Time Restriction
Hello Nathan -
Thanks for the information.
I have forwarded your mail to Mike so he can take a look, but it may be
a couple of days until he gets to it.
If you haven't heard back from me by the end of the week please contact
me again.
regards
Hugh
On 07/01/2004, at 11:49 AM, Nathan 'Franko' Franklin wrote:
Hugh,
No Time attributes work.
Kind Regards Nathan Franklin TSN Internet [EMAIL PROTECTED] MSN:
[EMAIL PROTECTED] 'Great managers meet deadlines and make money.
Great leaders meet the challenge and make history.'
- Original Message -
From: Hugh Irvine [EMAIL PROTECTED]
To: Nathan 'Franko' Franklin [EMAIL PROTECTED]
Sent: Wednesday, January 07, 2004 11:45 AM
Subject: Re: (RADIATOR) Time Restriction
Hello Nathan -
Thanks for the configuration and the trace.
Does this only happen for this particular check item? Or do other Time
checks work correctly?
I'm wondering whether the string Al-1600 is getting munged
during
processing.
regards
Hugh
On 07/01/2004, at 10:32 AM, Nathan 'Franko' Franklin wrote:
Hugh here is a copy of what you requested.
Thanks
=== START CONFIG ===
Trace 4
LogStdout
DictionaryFile dictionary
AuthPort 1810
AcctPort 1811
Client xx
Identifier xx
Secret xx
/client
Handler
PreAuthHook file:c:\hooks\preAuthHook_Emerald.pl
PostAuthHook file:c:\hooks\postAuthHook_Emerald.pl
DefaultSimultaneousUse 1
AuthLog SQL
DBSource dbi:ODBC:xx
DBUsername xx
DBAuth xx
Table radlogs
FailureQuery INSERT into RadLogs
(Username,Data,NASIdentifier,NASport,CallerID) values
('%n','%P','%N','%{NAS-Port}','%{Calling-Station-Id}')
/Authlog
AuthBy EMERALD
DefaultSimultaneousUse 1
Identifier AuthByEmerald
CaseInsensitivePasswords
DBSource dbi:ODBC:xx
DBUsername xx
DBAuth xxx
# You can add to or change these if you want.
AccountingTable radCalls
AcctColumnDef UserName,User-Name
AcctColumnDef CallDate,Timestamp,integer-date
AcctColumnDef AcctStatusType,Acct-Status-Type,integer
AcctColumnDef AcctDelayTime,Acct-Delay-Time,integer
AcctColumnDef AcctInputOctets,Acct-Input-Octets,integer
AcctColumnDef AcctOutputOctets,Acct-Output-Octets,integer
AcctColumnDef AcctSessionId,Acct-Session-Id
AcctColumnDef AcctSessionTime,Acct-Session-Time,integer
AcctColumnDef AcctTerminateCause,Acct-Terminate-Cause,integer
AcctColumnDef NASIdentifier,NAS-IP-Address
AcctColumnDef FramedAddress,Framed-IP-Address
AcctColumnDef NASPort,NAS-Port,integer
AcctColumnDef AscendSessionKey,Ascend-Session-Svr-Key
AcctColumnDef CallerID,Calling-Station-Id
AcctColumnDef NASPortDNIS,Called-Station-Id
AcctColumnDef SignaltoNoise,Annex-Signal-to-Noise-Ratio,integer
AcctColumnDef
Recievelevel,Annex-Begin-Receive-Line-Level,integer
AcctColumnDef ConnectSpeed,Connect-Info
AcctColumnDef Modulation,Annex-Begin-Modulation
AcctColumnDef NasHost,NAS-Identifier
StripFromReply Ascend-Data-Filter
/AuthBy
/Handler
=== END CONFIG ===
=== START TRACE ===
Wed Jan 7 10:22:58 2004: DEBUG: Packet dump:
*** Received from xx port 2909
Code: Access-Request
Identifier: 208
Authentic: 1234567890123456
Attributes:
User-Name = day1501
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = 123456789
Calling-Station-Id = 987654321
NAS-Port-Type = Async
User-Password =
$245D14139174[EMAIL PROTECTED]212189158m147
Wed Jan 7 10:22:58 2004: DEBUG: Handling request with Handler ''
Wed Jan 7 10:22:58 2004: DEBUG: Deleting session for day1501,
203.63.154.1, 12
34
Wed Jan 7 10:22:58 2004: DEBUG: do query is: 'delete from RADONLINE
Re: (RADIATOR) Problem with rewriteusername and chap
Hello Chris - I believe the problem is to do with MS-CHAP V2 which uses the full username to check the password. Have a look at the comment header and the code in Radius/MSCHAP.pm in the Radiator 3.8 distribution. regards Hugh On 08/01/2004, at 5:18 AM, Chris Simmons wrote: Dear all, First, I must say sorry for the log post (and html). Secondly, we have a client sending: username [EMAIL PROTECTED] MS-CAHP V2 and the password password. We are running a simple config.file: RewriteUsername s/[EMAIL PROTECTED]// Client DEFAULT Secret mysecret DupInterval 0 /Client Realm DEFAULT AuthBy FILE Filename /usr/local/etc/users /AuthBy /Realm the users file contains: user User-Password=password, user2 User-Password=password, But the following happens: Yeilds: Wed Jan 7 17:54:21 2004: DEBUG: Reading users file /usr/local/etc/users Wed Jan 7 17:54:21 2004: DEBUG: Finished reading configuration file '/usr/local/etc/simple.cfg' Wed Jan 7 17:54:21 2004: DEBUG: Reading dictionary file '/var/log/radius/dictionary' Wed Jan 7 17:54:21 2004: DEBUG: Creating authentication port 0.0.0.0:1813 Wed Jan 7 17:54:21 2004: DEBUG: Creating accounting port 0.0.0.0:1812 Wed Jan 7 17:54:21 2004: NOTICE: Server started: Radiator 3.8 on dns1 Wed Jan 7 17:54:25 2004: DEBUG: Packet dump: *** Received from 172.16.1.52 port 1814 Code: Access-Request Identifier: 13 Authentic: /s0126143149200R154239244tu_138 Attributes: MS-CHAP-Challenge = o167k193136128203138262141602301270K MS-CHAP2-Response = 10145228250/ r177E13148236%25182230Y- 1470246129b1815318832021781931654143@249s 28X1652162 User-Name =[EMAIL PROTECTED] NAS-IP-Address = 172.16.1.52 NAS-Identifier =[EMAIL PROTECTED]/24 Service-Type = Framed-User Framed-Protocol = PPP Proxy-State = 208 Wed Jan 7 17:54:25 2004: DEBUG: Rewrote user name to user Wed Jan 7 17:54:25 2004: DEBUG: Handling request with Handler 'Realm=DEFAULT' Wed Jan 7 17:54:25 2004: DEBUG: Deleting session [EMAIL PROTECTED], 172.16.1.52, Wed Jan 7 17:54:25 2004: DEBUG: Handling with Radius::AuthFILE: Wed Jan 7 17:54:25 2004: DEBUG: Radius::AuthFILE looks for match with user2 Wed Jan 7 17:54:25 2004: DEBUG: Radius::AuthFILE REJECT: Bad Password Wed Jan 7 17:54:25 2004: INFO: Access rejected for user: Bad Password Wed Jan 7 17:54:25 2004: DEBUG: Packet dump: *** Sending to 172.16.1.52 port 1814 Code: Access-Reject Identifier: 13 Authentic: /s0126143149200R154239244tu_138 Attributes: Reply-Message = Request Denied Proxy-State = 208 But if the follwoing is used: radpwtst [EMAIL PROTECTED] password the output below: *** Received from 127.0.0.1 port 60973 Code: Access-Request Identifier: 215 Authentic: 1234567890123456 Attributes: User-Name =[EMAIL PROTECTED] Service-Type = Framed-User NAS-IP-Address = 203.63.154.1 NAS-Port = 1234 Called-Station-Id = 123456789 Calling-Station-Id = 987654321 NAS-Port-Type = Async User-Password = 137234,163v14618889160216}x153 Wed Jan 7 18:05:05 2004: DEBUG: Rewrote user name to user2 Wed Jan 7 18:05:05 2004: DEBUG: Handling request with Handler 'Realm=DEFAULT' Wed Jan 7 18:05:05 2004: DEBUG: Deleting session [EMAIL PROTECTED], 203.63.154.1, 1234 Wed Jan 7 18:05:05 2004: DEBUG: Handling with Radius::AuthFILE: Wed Jan 7 18:05:05 2004: DEBUG: Radius::AuthFILE looks for match with user2 Wed Jan 7 18:05:05 2004: DEBUG: Radius::AuthFILE ACCEPT: Wed Jan 7 18:05:05 2004: DEBUG: Access accepted for user2 Wed Jan 7 18:05:05 2004: DEBUG: Packet dump: *** Sending to 127.0.0.1 port 60973 Code: Access-Accept Identifier: 215 Authentic: 1234567890123456 Attributes: BUT With rewriteUsername OFF and using MS-CHAP V2, and chaging the user anmes in the users file [EMAIL PROTECTED] It works. *** Received from 172.16.1.52 port 1814 Code: Access-Request Identifier: 14 Authentic: 20227JyPz8192168183245M252k139j Attributes: MS-CHAP-Challenge = 14l15825209199205a8J137u402146 MS-CHAP2-Response = 10F195ps4160|2502001763q213c24420 000175224269j1802203238? 157230231206184*192K194203y30 User-Name =[EMAIL PROTECTED] NAS-IP-Address = 172.16.1.52 NAS-Identifier =[EMAIL PROTECTED]/24 Service-Type = Framed-User Framed-Protocol = PPP Proxy-State = 80 Wed Jan 7 18:08:21 2004: DEBUG: Handling request with Handler 'Realm=DEFAULT' Wed Jan 7 18:08:21 2004: DEBUG: Deleting session [EMAIL PROTECTED], 172.16.1.52, Wed Jan 7 18:08:21 2004: DEBUG: Handling with Radius::AuthFILE: Wed Jan 7 18:08:21 2004: DEBUG: Radius::AuthFILE looks for match [EMAIL PROTECTED] Wed Jan 7 18:08:21 2004: DEBUG: Radius::AuthFILE ACCEPT: Wed Jan 7 18:08:21 2004: DEBUG: Access accepted [EMAIL PROTECTED] Wed Jan 7 18:08:21
(RADIATOR) No Proxy-State Attribute After Max Session Exceeded Reply
Hi,
I have noticed that the Proxy-State attribute is not being preserved in
the Access-Reject after a Max Sessions Exceeded
I was under the impression that Radiator would preserve the Proxy-State
attribute {from ref.html Radiator automatically copies any Proxy-State
attribute from the incoming Radius request to the reply}
We are currently running Radiator Ver 2.18.4
Short of writing a hook to put the Proxy-State attribute back in to the
reply packet, is there a way to make Radiator do it?
Following is a debug dump of the packets:
Thu Jan 8 16:52:11 2004: DEBUG: Packet dump:
*** Received from 203.194.59.120 port 1812
Code: Access-Request
Identifier: 60
Authentic:
c1511492091824213164[219237215H17238244
Attributes:
Framed-Protocol = PPP
CHAP-Password =
2201190151o176187155139+239173153~147
NAS-Port-Type = Virtual
NAS-Port = 2955
Calling-Station-Id = HIDDEN
Service-Type = Framed-User
NAS-IP-Address = 203.194.30.201
NAS-Identifier = HIDDEN
User-Name = [EMAIL PROTECTED]
Proxy-State =
HIDDEN/639795D11218D5A45BDBEDD74811EEF4DAB50998447F6AA9BA485C41C417D45DE549E7C1447F6F9D718A411090FEDFD41AB619D7AA77729A822B3
7B8B67CECAFD57BDF1D714756AC887C1FBDA773EDF89C26935A691B1DF694263AAD
Thu Jan 8 16:52:11 2004: INFO: Access rejected for [EMAIL PROTECTED]:
MaxSessions exceeded
Thu Jan 8 16:52:11 2004: DEBUG: Packet dump:
*** Sending to 203.194.59.120 port 1812
Code: Access-Reject
Identifier: 60
Authentic:
c1511492091824213164[219237215H17238244
Attributes:
Reply-Message = Request Denied
--
Cheers
Lee Webb
Systems Administrator
DOT Communications
[EMAIL PROTECTED]
===
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) No Proxy-State Attribute After Max Session Exceeded Reply
Hello Lee -
You should test this with Radiator 3.8, which should work correctly.
Please let me know if it doesn't.
regards
Hugh
On 08/01/2004, at 4:56 PM, Lee Webb wrote:
Hi,
I have noticed that the Proxy-State attribute is not being preserved in
the Access-Reject after a Max Sessions Exceeded
I was under the impression that Radiator would preserve the Proxy-State
attribute {from ref.html Radiator automatically copies any Proxy-State
attribute from the incoming Radius request to the reply}
We are currently running Radiator Ver 2.18.4
Short of writing a hook to put the Proxy-State attribute back in to the
reply packet, is there a way to make Radiator do it?
Following is a debug dump of the packets:
Thu Jan 8 16:52:11 2004: DEBUG: Packet dump:
*** Received from 203.194.59.120 port 1812
Code: Access-Request
Identifier: 60
Authentic:
c1511492091824213164[219237215H17238244
Attributes:
Framed-Protocol = PPP
CHAP-Password =
2201190151o176187155139+239173153~147
NAS-Port-Type = Virtual
NAS-Port = 2955
Calling-Station-Id = HIDDEN
Service-Type = Framed-User
NAS-IP-Address = 203.194.30.201
NAS-Identifier = HIDDEN
User-Name = [EMAIL PROTECTED]
Proxy-State =
HIDDEN/
639795D11218D5A45BDBEDD74811EEF4DAB50998447F6AA9BA485C41C417D45DE549E7C
1447F6F9D718A411090FEDFD41AB619D7AA77729A822B3
7B8B67CECAFD57BDF1D714756AC887C1FBDA773EDF89C26935A691B1DF694263AAD
Thu Jan 8 16:52:11 2004: INFO: Access rejected for [EMAIL PROTECTED]:
MaxSessions exceeded
Thu Jan 8 16:52:11 2004: DEBUG: Packet dump:
*** Sending to 203.194.59.120 port 1812
Code: Access-Reject
Identifier: 60
Authentic:
c1511492091824213164[219237215H17238244
Attributes:
Reply-Message = Request Denied
--
Cheers
Lee Webb
Systems Administrator
DOT Communications
[EMAIL PROTECTED]
===
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.
NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.
===
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.
