Re: attribute type error
On 1/7/2013 22:48 PM, Yashaswini Sathyanarayana wrote: Hi , By default all standard attribute like user-name, user-password are of type 1 and length 1. But kineto attributes are of type 2 and length 2. So is there a way to make RFC-2865 dictionary that is added in free radius to type 2. Please help. The format is 2,1 not 2,2. The dictionary file specifically tells us FreeRadius understands the format. # Note: format=2,1 indicates to freeRADIUS that vsaType=2bytes, and vsaLen=1byte # VENDOR Kineto 16445 format=2,1 FreeRadius can handle these long tag VendorSpecific attributes. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Strip off the domain part from the User-Name
The MSCHAPs include the given name when calculating the hashes.
Stripping the domain will therefore not work. The client is using the
domain\name in the hash and you're asking the server to use just the name.
On 3/23/2011 15:08 PM, Thomas Wunder wrote:
Hi,
I'm currently trying to configure my Win7 clients to do wired 802.1X authentication using
the credentials a user provides at the login screen. Wired 802.1X auth itself works fine
but as soon as I have it use the logon credentials (using the Automatically use my
Windows logon name and password (and domain if any).) Windows sends User-Names like
'computername\\username'. That's normal so far I think.
To get the rlm_ldap related stuff working I simply changed my filter and groupmembership_filter
settings in modules/ldap to be [...]uid=%{mschap:User-Name:-%{User-Name}}[...] instead
of [...]uid=%{%{Stripped-User-Name}:-%{User-Name}}[...] and that works well.
But when it comes to MSCHAP authentication I've got a problem:
I get errors like
[mschap] ERROR: User-Name (testpc\tom1) is not the same as MS-CHAP Name (tom1) from
EAP-MSCHAPv2
(...which sounds consequent) I've tried solve that problem by changing
with_ntdomain_hack = yes (I know you recommend against that) without any luck:
+- entering group authenticate {...}
[eap] Identity does not match User-Name, setting from EAP Identity.
[eap] Failed in handler
++[eap] returns invalid
Failed to authenticate the user.
Login incorrect: [tom1] (from client swtswitch01 port 0 via TLS tunnel)
Somewhere I've read that in such a case one should use the realms concept but I
can't seem to get it working. There's an entry like
realm ntdomain {
format = prefix
delimiter = \\
}
in the modules/realm but what else do I need?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: The decoded content is not same as command in CoA
Perhaps the character value of the string for zero ('0') is 30 in hex
(0x30).
On 1/12/2011 23:33 PM, Xiaochen wrote:
Dear all,
I am using Fedora 12 + Freeradius to do some CoA tests.
One is : AAA sends Disconnect request to Client.
My packet.txt content is as:
WiMAX-DM-Action-Code=0
But when I run it in the command terminal, the screen said as below:
-
WiMAX-DM-Action-Code = 0x30
I don't know why WiMAX-DM-Action-Code content was changed.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Doubt - Freeradius + Ldap
There's many a slip 'twixt the cup and the lip I promise you'll want to kick yourself when you find the simple difference after so many messages. Many of us have the grace to go through this necessarily humbling exercise in private. On 2010-11-05 2:47 PM, Eduardo Moreira wrote: sorry, but where i checked the shared secret? in clients.conf? if yes, secret is ok! thanks for any help. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: still not working (newbie for radius)
By the looks of it you have two problems. The User-Password name 'bob'
isn't matched by the response Juniper-Local-User-Name 'labrat'. Perhaps
ssh cares.
Your broken client sends the identical packet for the new authentication
attempt when it must send a brand new packet (different id, socket or
port). That's why the server drops subsequent login attempts from ssh -
they're duplicate requests which the server has already answered.
In your second attempt you're User-Name is 'labrat' and the
Juniper-Local-User-Name 'labrat' is being returned in the response
probably convincing SSH you are who you claim to be.
On 2010-09-19 9:35 PM, gahn wrote:
thanks tim:
yes, it is better but yet working correctly:
g...@giraffe:~:$ ssh b...@192.168.255.138
b...@192.168.255.138's password:
Permission denied, please try again.
b...@192.168.255.138's password:
Permission denied, please try again.
b...@192.168.255.138's password:
Permission denied (publickey,password,keyboard-interactive).
but trying local username labrat is working fine:
g...@giraffe:~:$ ssh lab...@192.168.255.138
lab...@192.168.255.138's password:
--- JUNOS 8.5R4.3 built 2008-08-12 23:16:55 UTC
lab...@lab-r8
what is interesting here is that now i can see Access-Accept in the debugging messages
of radiusd -X:
rad_recv: Access-Request packet from host 192.168.255.138 port 65003, id=3,
length=57
User-Name = bob
User-Password = bob
NAS-Identifier = lab-r8
NAS-IP-Address = 150.150.0.1
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = bob, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[unix] returns notfound
[files] users: Matched entry bob at line 1
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns updated
Found Auth-Type = PAP
+- entering group PAP {...}
[pap] login attempt with password bob
[pap] Using clear text password bob
[pap] User authenticated successfully
++[pap] returns ok
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 3 to 192.168.255.138 port 65003
Juniper-Local-User-Name = labrat
Finished request 4.
Going to the next request
Waking up in 4.9 seconds.
rad_recv: Access-Request packet from host 192.168.255.138 port 65003, id=3,
length=57
Sending duplicate reply to client r8 port 65003 - ID: 3
Sending Access-Accept of id 3 to 192.168.255.138 port 65003
Waking up in 1.9 seconds.
Cleaning up request 4 ID 3 with timestamp +91
Ready to process requests.
rad_recv: Access-Request packet from host 192.168.255.138 port 65003, id=3,
length=57
User-Name = bob
User-Password = bob
NAS-Identifier = lab-r8
NAS-IP-Address = 150.150.0.1
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = bob, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[unix] returns notfound
[files] users: Matched entry bob at line 1
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns updated
Found Auth-Type = PAP
+- entering group PAP {...}
[pap] login attempt with password bob
[pap] Using clear text password bob
[pap] User authenticated successfully
++[pap] returns ok
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 3 to 192.168.255.138 port 65003
Juniper-Local-User-Name = labrat
Finished request 5.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 5 ID 3 with timestamp +97
Ready to process requests.
--- On Sun, 9/19/10, Tim Sylvestertim.sylves...@networkradius.com wrote:
From: Tim Sylvestertim.sylves...@networkradius.com
Subject: RE: still not working (newbie for radius)
To: 'FreeRadius users mailing list'freeradius-users@lists.freeradius.org
Date: Sunday, September 19, 2010, 5:52 PM
well, i had tried other configuration for users:
bob Cleartext-Password = bob
Juniper-Local-User-Name = labrat
labrat is local login user id so that all of radius users
will be mapped to
that user. unfortunately, it is also failed though with no
warning messages:
tim You are missing a : - try the following:
bob Cleartext-Password := bob
Juniper-Local-User-Name =
labrat
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: still not working (newbie for radius)
I'm merely speculating that your SSH client is rejecting the response
where the User-Name Juniper-Local-User-Name for 'bob' but accepts the
name 'labrat' and response name 'labrat'.
well, i don't have user labrat configured in file users on the
radius server.
KISS:
Set up the server to test the Juniper-Local-User-Name responses. You
might consider testing just that side of things 'til you figure out the
pattern. This part is not a RADIUS problem.
BTW the Access-Request packet should use either the NAS-Identifier OR
the NAS-IP-Address but not both. Something is likely to mysteriously
break later. Choose one.
also you are right, for some reasons, every login attempt will have
two more duplicated messages besides the first one. why is that?
The RADIUS server is working properly. Your client is not.
Your RADIUS client sends an identical packet for each different attempt
to log in. This is just plain wrong and the server is replying with a
copy of the original response.
Either the client is broken or SSH is misusing the client.
On 2010-09-19 11:19 PM, gahn wrote:
thanks.
well, i don't have user labrat configured in file users on the
radius server. the labrat is in local user password database on the
juniper box. for the raqdius support on juniper routers, it must map
a remote user (in the database of radius server) to a specific local
user. in my case, i map the radius username bob to the juniper
local username labrat.
if i understand correctly what you were saying, this attribute of
Juniper-Local-User-Name is not working?
also you are right, for some reasons, every login attempt will have
two more duplicated messages besides the first one. why is that?
I am really new on this. thanks for the help...
--- On Sun, 9/19/10, Michael Lecuyerm...@iterpacis.org wrote:
From: Michael Lecuyerm...@iterpacis.org Subject: Re: still not
working (newbie for radius) To: FreeRadius users mailing
listfreeradius-users@lists.freeradius.org Date: Sunday,
September 19, 2010, 7:26 PM By the looks of it you have two
problems. The User-Password name 'bob' isn't matched by the
response Juniper-Local-User-Name 'labrat'. Perhaps ssh cares.
Your broken client sends the identical packet for the new
authentication attempt when it must send a brand new packet
(different id, socket or port). That's why the server drops
subsequent login attempts from ssh - they're duplicate requests
which the server has already answered.
In your second attempt you're User-Name is 'labrat' and the
Juniper-Local-User-Name 'labrat' is being returned in the response
probably convincing SSH you are who you claim to be.
On 2010-09-19 9:35 PM, gahn wrote:
thanks tim:
yes, it is better but yet working correctly:
g...@giraffe:~:$ ssh b...@192.168.255.138 b...@192.168.255.138's
password: Permission denied, please try again.
b...@192.168.255.138's password: Permission denied, please try
again. b...@192.168.255.138's password: Permission denied
(publickey,password,keyboard-interactive).
but trying local username labrat is working fine:
g...@giraffe:~:$ ssh lab...@192.168.255.138
lab...@192.168.255.138's password: --- JUNOS 8.5R4.3 built
2008-08-12 23:16:55 UTC lab...@lab-r8
what is interesting here is that now i can see
Access-Accept in the debugging messages of radiusd -X:
rad_recv: Access-Request packet from host
192.168.255.138 port 65003, id=3, length=57
User-Name = bob User-Password =
bob
NAS-Identifier =
lab-r8
NAS-IP-Address =
150.150.0.1
+- entering group authorize {...} ++[preprocess] returns ok
++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in
User-Name = bob, looking up realm
NULL
[suffix] No such realm NULL ++[suffix] returns noop [eap] No
EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns
notfound [files] users: Matched entry bob at line 1 ++[files]
returns ok ++[expiration] returns noop ++[logintime] returns
noop ++[pap] returns updated Found Auth-Type = PAP +- entering
group PAP {...} [pap] login attempt with password bob [pap]
Using clear text password bob [pap] User authenticated
successfully ++[pap] returns ok +- entering group post-auth
{...} ++[exec] returns noop Sending Access-Accept of id 3 to
192.168.255.138 port
65003
Juniper-Local-User-Name = labrat
Finished request 4. Going to the next request Waking up in 4.9
seconds. rad_recv: Access-Request packet from host
192.168.255.138 port 65003, id=3, length=57
Sending duplicate reply to client r8 port 65003 - ID:
3
Sending Access-Accept of id 3 to 192.168.255.138 port
65003
Waking up in 1.9 seconds. Cleaning up request 4 ID 3 with
timestamp +91 Ready to process requests. rad_recv: Access-Request
packet from host
192.168.255.138 port 65003, id=3, length=57
User-Name = bob User-Password =
bob
NAS-Identifier =
lab-r8
NAS-IP-Address =
150.150.0.1
+- entering group authorize {...} ++[preprocess] returns ok
++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in
User-Name = bob, looking up
Re: Construction of Response-Authenticator
No one here is going to do your homework for you. RFC 2865 is pretty clear on how this is calculated. A Message-Authenticator attribute in the response attributes will require more work. Perhaps you can get extra credit for figuring it out. On 2010-09-12 1:25 PM, Theresa Otte wrote: Hello, I use FreeRADIUS 2.1.8 on Ubuntu 10.4. For my course at university I have to write a program in which I need to re-calculate the response-authenticator (MD5(Code+ID+Length+Request-Auth.+Attributes+Secret)). Does anybody know how FreeRADIUS calculates it? Does it take the binary code of the message fields or an other encoding? When I try to re-calculate it, I never get the same Response-Authenticator as in the Access-Accept-Message. I'm programming with Python and using the libraries of scapy and hashlib. Perhaps anyone of you can help me. Thank you very much! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Of accounting data and security
TACACS+ uses an MD5 pad based on the session ID, shared secret, TACACS+ version, and packet sequence number. This is XOR'd over the packet. The pad is in multiples of the MD5 hash length. The header is sent plain text and includes the sequence number, the session ID and version number. Encoding and decoding are symmetrical. It is not considered strong encoding. We're all fortunate RADIUS doesn't use this to encode packets. Natr Brazell wrote: Thanks, I'm looking into IPSEC at the moment. I'm curious how TACACS+ does their encryption? N On Fri, Aug 6, 2010 at 4:09 PM, Alan DeKok al...@deployingradius.com mailto:al...@deployingradius.com wrote: Natr Brazell wrote: Is there a way to secure the communication between the radius server and the NAS especially wrt accounting data? IPSec. Most NASes implement IPv4, and not much else. Security means don't run RADIUS over a network where users have access. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Of accounting data and security
We would be stuck with static weak security built in to RADIUS just like TACACS uses. There are options for securely tunneling RADIUS packets that weren't available in the early years. Secure tunneling doesn't require changes to the RADIUS protocol. The EAP-TLS extension alone has made most of RADIUS secure. For TACACS changing the encoding means re-writing every client and server. Tunneling TCP through SSL takes way too many packets to efficiently perform a large number of each separate authentication, authorization and accounting transaction. Built in transport security is a bad idea. For TACACS it is the only way since PAP/ASCII authentication and password changes really are sent in plain text. Please, no more talk of TACACS. Its not a good example of anything. Natr Brazell wrote: Curious why we're fortunate? Could you elaborate some? On Sun, Aug 8, 2010 at 10:01 PM, Michael Lecuyer m...@iterpacis.org mailto:m...@iterpacis.org wrote: TACACS+ uses an MD5 pad based on the session ID, shared secret, TACACS+ version, and packet sequence number. This is XOR'd over the packet. The pad is in multiples of the MD5 hash length. The header is sent plain text and includes the sequence number, the session ID and version number. Encoding and decoding are symmetrical. It is not considered strong encoding. We're all fortunate RADIUS doesn't use this to encode packets. Natr Brazell wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Master key and Pairwise Master Key encryption
I'm not sure it would help you to know how the Master Keys are generated or encoded - it's not simple. It's a process involving the accumulated TLS handshake messages, random number generation, various sorts of key exchanges, cryptographic hashes, and the PRF function described in the TLS RFC's. Not really casual reading. TTLS and TLS use different TLS PRF (Pseudo-Random Function) labels to generate the key material. The MMPE RFC 3079 describes the generation of the master MPPE keys from the PRF and how the supplicant should use them. Some of us find this casual reading :) Encoding attribute data is done using a salt encoding described in RFC 2548 with a Microsoft modification described in some MPPE RFC. The 'code' is scattered throughout the FR rlm source (those dealing with TLS and the many mschap's) and in the separate OpenSSL source dealing with SSL/TLS. However, in FR, it just automagically works. Khan Ferdous Wahid wrote: Hi, I want to know about the Master key (MK) encapsulation and Pairwise Master key (PMK) generation during EAP-TLS or EAP-TTLS methods. When the supplicant is authenticated, the server generates a MK and sends it in encrypted format to the supplicant. How this MK (I think it is a random number) is encrypted? Which algorithm is used and which parameters are included (input) to disguise the MK? Then how the PMK is generated independently inside server and supplicant? What algorithm and parameters are used to cryptically pass the PMK to authenticator (Access point)? Please tell me clearly because I am a newbie. Which source codes include these operations, where should I look? Thank you. /Khan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Encrypted password with FR+LDAP+Wireless Network
The password is encoded for PAP (when a User-Password is present). Its the only authentication method that uses decodable passwords. FR is displaying it in plain text for your convenience. Inýcio Alves wrote: Good Morning to all. I would like if is possible use FR+LDAP with Use-Password encrypted? I'm using FR 2.1.8 + OpenLDAP 2.4.21. I'm trying configure FR to authenticate users in wireless network. This is my debug output. When I try a radtest with login/pass from the users file I don't get warning, but LDAP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: NAS-IP vs srcIP
Plenty of reasons - but one you won't have control over even in CoA is that it could be proxied. The NAS-IPAddress is used in the CoA request packet to tell the NAS which client should receive the packet. Marlon Duksa wrote: Hi everyone - Can anyone think of a reason why the NAS-IP and the scr-IP of the access-req packet should not be the same? If the NAS-IP is configurable in the NAS, then the NAS-IP can be set to the IP address other than the src-ip of the NAS that is used in reqular FreeRadius accounting/authorization packets. The source IP address of the NAS is normally the native interface address from which access-req was sent (but it can be configurable). The NAS-IP would be used to address NAS in CoA requests sent from the FreeRadius. We need this behavior to address certain deployment requirements. for example: IP prot: srcIP: 1.1.1.1 dstIP: 2.2.2.2 Radius prot: code: access-request (1) AVPs: NAS-IP-Address: 3.3.3.3 scrIP != NAS-IP-Address Thanks, Marlon - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radpostauth question
It's a one-way hash of the password. What you're seeing is the CHAP password value. Only PAP uses a reversible password. Sallai Janos wrote: Hi, Does anyone knows how I could save the CHAP password into radpostauth pass in a VISIBLE format, in mysql ? Actually I can correctly log both the successful and unsuccessful authentications, but I can see only the PAP auth in a visible format. Is there a chance to configure freeradius to see a visible chap-password when quering in mysql , not the 0xea8c35456432dd70a3bbe3ef701a669a13 encrypted formula ? thanks, John - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: stress test or performance test result
Evolynx is not very good (quite poor). It uses long fixed time outs for packets which really only tells how fast the client is, not the server. Almost all simple load tests have this problem. All RADIUS systems will bog down with back end issues like LDAP and accounting databases. Test those instead. This mailing list is full of these back end issues. Heavy duty crypto can affect speed but that's part of cryptography's charm. Nizar Zulmi wrote: i do test my RADIUS using EvoLynx load test, do you using this also..??please just send me your result, it just to comparing my result test to know does my result is categories on fast result or slow..and it also to show my lecture that anyone has did stress test with Evolynx radius test and got accurate result. --- On *Mon, 6/1/09, Marinko Tarlac /mangi...@gmail.com/* wrote: From: Marinko Tarlac mangi...@gmail.com Subject: Re: stress test or performance test result To: FreeRadius users mailing list freeradius-users@lists.freeradius.org Date: Monday, June 1, 2009, 5:08 PM Hi there Right now I'm working on some tests but results won't be ready for publishing until next week. Right now I noticed that default 5.0.45 mysql who goes with RH/CentOS Fedora is very slow... Specially with innodb tables... On Mon, Jun 1, 2009 at 11:51 AM, Nizar Zulmi siapa_bilang_emailku_panj...@yahoo.com /mc/compose?to=siapa_bilang_emailku_panj...@yahoo.com wrote: dear all.. i want to compare my RADIUS server result test with someone who perform stress test or performance test. please anyone has did performance test or stress test send me the result, it could be screenshoot or anything related to. it just for compare. thank you. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -Inline Attachment Follows- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius user-password on the wire
The User-Password value is a MD5 chained pad based on the shared secret and packet authenticator. The password is XOR'd over the pad and this is chained to the next pad. The process is reversible. Essentially this is as close to a perfect encryption scheme as you can get - entirely depending on the cryptographic strength of the authenticator's randomness, the shared secret, and the MD5 message digest algorithm. It's probably good enough depending on who's snooping. Computer randomness is not great, the MD5 algorithm has collisions, and your shared secret could be poor or compromised. Riccardo Veraldi wrote: Hello, I used wireshark to sniff communication between my radisu server and the user-password attribute is encrypted 3e ca 2d b0 97 2b b3 f9 0c e9 fc e7 e0 ed e9 fd to test if this is strong enough I wanted to ask if there is a way to decrypt this user-password attribute since my radisu server is doign proxy to other radius server. actually my radius server is authenticating a WiFi captive portal and is prosying requests upon [EMAIL PROTECTED] user attributes are stripped from domain and sent to proper radius server my question is how much is risky to have user-passsword attribute travellign across the network ? is the encryption applyed to the user-password strong enough ? thanks Rick - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: incorrect shared secret entry authenticates successfully forfreerradius
NTRadPing is a very bad client to test real authentication. While it says it has an Access-Accept packet it isn't doing any proper checking of the packet. All Access-Accept packets are signed by the server using the shared secret. A good client will check that signature. A packet with a bad signature is rejected by a proper client even though the server sent an Access-Accept. Your test and discussion are pointless because the client NTRadPing is not telling you that the packet is invalid. It's just displaying the packet's contents. PAP is the only authentication method where you would get an Access-Reject with a bad secret. [EMAIL PROTECTED] wrote: Hi Phil, I checked the issue with MSCHAP v1 and v2 as well. Even there the authentication passes for an incorrect secret key Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] dius.org] On Behalf Of Phil Mayers Sent: Tuesday, March 18, 2008 7:24 PM To: FreeRadius users mailing list Subject: Re: incorrect shared secret entry authenticates successfully forfreerradius [EMAIL PROTECTED] wrote: Hi, I am using the following configuration: O/S: rhel4_u5_i386 Freeradius 1.1.7 Client to test: NTRadPing 1.5 Steps undertaken: - Installed a fresh system with rhel4_u5_i386 - Build and compile freeradius 1.1.7 on it. - Update the clients.conf file to add the client entries for the machine that uses NTRadPing 1.5 (IP of the client machine and the shared secret) - Start the radiusd daemon in debug mode (radiusd -X) - Now generate a simple PAP authentication request using NTRadPing. (Port is 1812, also provide the shared secret correctly). The authentication passes successfully as it should. Now give a junk secret key in the NTRadPing utility. The access is rejected. - However when the same cases are tried for CHAP we can see the difference. In the first case the authentication is successful; however when we give a junk shared secret the authentication should ideally have been rejected. However the authentication passes successfully. NOTE: I tried the same for MSCHAPv1 and MSCHAPv2 authentication using VPN client. There I can see clearly that the access is not granted to the VPN client. However when we look at the radius logs it can be seen that the Authentication requests responds with a Successful message. Any help or info in this regards would be highly appreciated. Only certain radius AVPs are encrypted with the shared secret: fgrep encrypt /usr/share/freeradius/dictionary* User-Password is one, so PAP fails if the shared secret is wrong. The CHAP attributes are not, so the request succeeds. The MS-CHAP-MPPE-Keys or MS-MPPE-Send-Key/MS-MPPE-Recv-Key reply attributes are encrypted, so MS-CHAP will fail. Many recent radius clients support the Message-Authenticator attribute, which is a signature over the entire packets AVPs encrypted with the shared secret. This will cause incorrect shared secrets to reject an entire packet. See section 3.2 of RFC3579. If your NAS supply Message-Authenticator, you could refuse packets without one: DEFAULT Message-Authenticator !* ANY, Auth-Type := Reject - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RADIUS Stress Test tool
Like most other RADIUS server load testers it merely tests how fast the client load test can run and doesn't really test the server load. The Evolynx tester is especially prone to this problem because you can't set the client time out. And 20 concurrent threads won't result in much of a load. And CPU load may not be much of a measure of a server's capacity. In a number of my own tests I've found that the shorter the time out the faster the server appears to run with only slightly more packets being dropped. What we're seeing is that a long time out can make it appear that all packets are being processed but the long time out also slows the client load test. If half of those threads are waiting a very short time for responses and half are waiting a long time (essentially waiting for the short responses to be processed by the server) you're now down to half the threads testing the server. As time goes by more and more threads are waiting for fewer quick thread responses and the test becomes meaningless. Being able to set the time out to something like one tenth of a second can show a significant increase in server packets processed with only a slight increase in dropped packets for simple authentication methods. A dramatic increase in packet loss usually shows a back end problem. The only real way to load test a server is to run many tests from many machines. For example, I saw the graph of over 100,000 customers using a RADIUS accounting server. The dropped packet count was sloping up gradually as the morning progressed and more people were using the system. Finally the back end server completely bogged down and then the dropped packets spiked enormously as customers started re-accounting causing a complete failure of the system from which it wouldn't recover until most of the customers gave up. That's the test you're looking for and that's the load you want :) Kostas Kalevras wrote: O/H [EMAIL PROTECTED] έγραψε: You do. ;-) If you have freeradius you have radiusclient. Ivan Kalik Kalik Informatika ISP Dana 4/10/2007, Amr el-Saeed [EMAIL PROTECTED] piše: Dear All, Does any one have any tool to stress test the freeRadius ?? http://www.evolynx.com/radius/dl_loadtest.aspx regards, Amr el-Saeed - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Accounting Request Message Authenticator setting to 0x00
It's impossible to put an Message-Authenticator in an accounting packet. It has to do with the way the Accounting-Request packet is signed. The MA is placed in the Access-Request packet as 16 zeroed bytes. The HMAC-MD5 value is calculated over the entire packet and patched into the MA's zeroed value. Since the authenticator is a random number the MA's value does not matter when back patched in the packet. An accounting packet (Accounting-Request) is signed by performing an MD5 over the entire packet and then stuffing that value into the authenticator's position. So the accounting packet is already securely signed and doesn't need another signature on top of that. It would be impossible to calculate the MA since the authenticator starts out zeroed in an accounting packet. When the accounting packet is signed either a precalculated MA will be incorrect or a post-authenticated MA will invalidate the accounting packet's signature. Archna Mittal wrote: Hi, I am a newbie to Radius Protocol. I want to set the Message Authenticator value to 0x00 in my Accounting Request. I have tried bzero but its not working. Please let me know if there is a way to do it? Thanks Regards, Regards, -Archna - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Accounting Request Message Authenticator setting to 0x00
If your accounting-request is damaged then the server will reject it since the signature will be altered. The server performs a signature check on the Accounting-Request - basically resigning it and checking that the resulting Accounting-Request authenticators are the same. It's a trust mechanism based on which end is responsible for the consequences of the transaction. When authenticating the client doesn't trust the server and requires that the server sign the response packet. The client will grant privileges and so cannot afford to blindly trust the server. In accounting the server doesn't trust the client and requires a signed packet from the client. In this case the server doesn't want to trust just any old packet for something as important as accounting. [EMAIL PROTECTED] wrote: Lets say you achieve that with some packet sniffing software. You don't have radius packet any more. You have garbage. What now? Ivan Kalik Kalik Informatika ISP Dana 16/3/2007, Archna Mittal [EMAIL PROTECTED] piše: Is it possible to put authenticator filed in Accounting Request message to 0x00? Regards, -Archna -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ius.org] On Behalf Of Michael Lecuyer Sent: Thursday, March 15, 2007 6:47 PM To: FreeRadius users mailing list Subject: Re: Accounting Request Message Authenticator setting to 0x00 It's impossible to put an Message-Authenticator in an accounting packet. It has to do with the way the Accounting-Request packet is signed. The MA is placed in the Access-Request packet as 16 zeroed bytes. The HMAC-MD5 value is calculated over the entire packet and patched into the MA's zeroed value. Since the authenticator is a random number the MA's value does not matter when back patched in the packet. An accounting packet (Accounting-Request) is signed by performing an MD5 over the entire packet and then stuffing that value into the authenticator's position. So the accounting packet is already securely signed and doesn't need another signature on top of that. It would be impossible to calculate the MA since the authenticator starts out zeroed in an accounting packet. When the accounting packet is signed either a precalculated MA will be incorrect or a post-authenticated MA will invalidate the accounting packet's signature. Archna Mittal wrote: Hi, I am a newbie to Radius Protocol. I want to set the Message Authenticator value to 0x00 in my Accounting Request. I have tried bzero but its not working. Please let me know if there is a way to do it? Thanks Regards, Regards, -Archna - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Disconnect user in radius
You can send a Disconnect-Message from the RADIUS server to the client to disconnect them if the NAS supports DM/COA. The DM will cause the NAS to drop the connection effectively disconnecting them from any services they were using. Dennis Skinner wrote: satish patel wrote: I have useing freeradius with microsoft mssql now my question is how do i disconnect user from freeradius means example:- user xyz is online and i want to disconnect user from radius so what is the option for this task ?? is there any script or any option to integrate with webpage of dialupadmin ??? You need to change your thinking. The user is not connected to RADIUS. Never was. That isn't what RADIUS does. The user is connected to your NAS. Check the NAS docs for disconnecting a user. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: CHAP on freeradius mysql
You're requiring MS-CHAP authentiation but the client is sending a CHAP authentication. They're not the same type of authentication. John Longland wrote: Hi all My freeradius server has been running for some time now and due to the users file getting a bit long, I decide to go with the mysql-database. I have my PAP-clients running on the new mysql-radius setup but my CHAP clients are still failing. When I was running from the users-file, an entry would look like this: DEFAULT Auth-Type = MS-CHAP, Password == void, Calling-Station-ID == '27111' Framed-IP-Address = 1.2.3.4 but moving to mysql, I cannot have as usernames. So my radcheck table has johnAuth-Type MS-CHAP john User-Password john johnCalling-Station-ID 27111' When I run radiusd in debug mode, it says modcall : module sql returns ok for request 1 rlm_chap login attempt by john with CHAP-password rlm_chap: Using clear text password john for user john authentication rlm_chap : Password check failed Is there any othe rdebugging aids that I can switch on to see whats cooking ?? Thanks ! John - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RADIUS AUTHENTICATOR---need HELP using MSCHAP and NTPASSWORD
This pretty much sums up the problem: rlm_mschap: No MS-CHAP-Challenge in the request This is not a valid MS-CHAP request. You might want to look at the actual attributes passed to see if this is really an MS-CHAP request. It will contain Microsoft VSAs containing a MS-CHAP-Challenge and a MS-CHAP-Response. ego seek wrote: I use Squid and RADIUS. Squid use Squid_radius_authenticator to authenticate a client and write a log in which there is the username and the http request. THE PROBLEM IS: In the radcheck table i put a value: AUTH-TYPE and set MS-CHAP for the user. his password is stored in NT-HASH format. when the authenticator try to authenticate the user, this is the output ... rad_check_password: Found Auth-Type MS-CHAP auth: type MS-CHAP Processing the authenticate section of radiusd.conf modcall: entering group MS-CHAP for request 6 rlm_mschap: No User-Password configured. Cannot create LM-Password. rlm_mschap: Found NT-Password rlm_mschap: No MS-CHAP-Challenge in the request modcall[authenticate]: module mschap returns reject for request 6 modcall: leaving group MS-CHAP (returns reject) for request 6 auth: Failed to validate the user. Login incorrect:[username/password] can anybody help me? please. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Hiding Passwords in Debug Output
Debugging output is always a security exposure. Secure debugging wouldn't be all that helpful to the debugging process especially as seeing the plain text password may be the difference between solving a problem or not. Perhaps 'redacted' debugging output is what you're after (for posting to the mailing list). Perhaps you could add a radiusd flag for that and change the debugging output accordingly. Garber, Neal wrote: I understand that it is sometimes useful to display the plain-text password in the debug output; however, I consider this a security exposure. I’d like to see a configuration option (e.g., debug_show_passwords or something similar) with a default of no, that when set to false/no would write “” instead of a plain-text password in debug output. Currently, modules rlm_ldap, rlm_pap, and perhaps others write the plain-text password in debug output. Your thoughts? Neal - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius Domain name ( website) registration expired ?
I'm directed to www.domaindirect.com. However a 'whois' shows: Expiration Date:19-Nov-2007 05:00:00 UTC Registrant Name:Alan DeKok Status:CLIENT TRANSFER PROHIBITED so it's unlikely that that the domain has expired or has been hijacked. However the name servers are on domaindirect.com so perhaps the DNS has messed up or there's some maintenance going on. Jeff Green wrote: Can anyone else get to http://www.freeradius.org ? I'm getting redirected to a domain name registration of some ISP. Seems like the domain names registration has expired ??? Confidentiality Note: The information contained in this email and document(s) attached are for the exclusive use of the addressee and may contain confidential, privileged and non-disclosable information. If the recipient of this email is not the addressee, such recipient is strictly prohibited from reading, photocopying, distribution or otherwise using this email or its contents in any way. Please notify the Sapiens (UK) Ltd. Systems Administrator via e-mail immediately at [EMAIL PROTECTED], if you have received this email in error. Disclaimer: The views, opinions and guidelines contained in this confidential e-mail are those of the originating author and may not be representative of Sapiens (UK) Ltd. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP LDAP confusion
Rob Shepherd wrote: The setup uses PEAP, however am I correct in thinking that the RADIUS server never touches any TLS components. The TLS tunnel is between the WLAN controller and the client right? PEAP - Protected EAP - the protection is the TLS tunnel which is between the RADIUS client and RADIUS server. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with secrets
This has been explained before in this list and it's how RADIUS works. The Even though the secret is incorrect the authentication can be correct. The server returns an Access-Accept. Why? The server trusts the client (it's in the accepted NAS list) and performs the authentication. The server then signs the response packet with it's version of the secret. The client doesn't trust the server and checks the signature. If the signature is not correct the client rejects the packet. The opposite is true with accounting packets - the client signs the request and the server checks the signature. The Message-Authenticator attribute can be used to sign the Access-Request packet which will cause the server to reject a packet with the an incorrect MA signature. David Goodenough wrote: I just hit a really odd problem with a secrets. We were asked to use FreeRadius to provide IP addresses to an Ericsonn NAS. We set up the server and have some test clients with simple secrets. If those are right it works, if they are wrong it fails. Then we put in the secret for the Ericsonn (I can not put it in this note as it is someone else's secret and I do not know what else it might be the secret for, but privately I could make it available for testing). This secret is 13 digits long, mixed numbers and letters, looks reasonably random, and in the proper secret all the letters were upper case. However somehow one of the letters (an O) got put into the server in lower case. The server happily accepts Access-Request packets with an authenticator built from the all upper case secret, even though its secret was different, it was only the client which rejected the Access-Accept. Diagnosing this however was very difficult as we had no access to the Ericsonn box and any console messages it might log (we could only see what went on the wire and whether the connection succeeded). A quick look at the code did not find anywhere where the secret gets folded to all upper case (but I might have missed it) and if there were such folding it would be unfortunate if this was only done on checking the received packet not on generating the reply. I am new to RADIUS, and I could not find any rules about case folding for secrets, but I might have missed them. It could simply be one of those freak places where the MD5 checksum happens to be the same for the request but not the response, but that does not feel right. I am using 1.1.1 (I am also using JRadius which last time I looked only produced patches for 1.1.1, not 1.1.2). David - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RE : Problem with secrets
Most authentication methods don't use the secret as part of the password encoding and use independent information for encoding. PAP is the only authentication method that depends on the secret. For example CHAP uses the password, two random numbers and MD5 to encode the password. Thibault Le Meur wrote: Even though the secret is incorrect the authentication can be correct. The server returns an Access-Accept. Why? The server trusts the client (it's in the accepted NAS list) and performs the authentication. I might have missed something here, sorry in advance ;-) Since the secret is incorrect, Freeradius wont be able to correctly decrypt the user-password. So authentication shouldn't be succesful ? (section 4.1 of http://www.freeradius.org/faq/). Have you got any pointer to the thread you are talking about (I haven't found it with a wuick googleing) ? Thibault - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeRadios rlm_sql dumps if databaase server hiccups
I think that authenticating everyone if the database went down would be called 'foolsafe' :) If your database is down you're out of business. There are much better 'failsafe' methods - search for fail-over in the FreeRadius documentation. Matt wrote: Ok, Well with no answer to this question let me ask it another way... In the event of database (via ODBC) failure... is there a way I can make the radius server go into failsafe mode, and just authenticate anything? On 6/15/06, Matt [EMAIL PROTECTED] wrote: Hi, We use FreeRadius with unixODBC and the rlm_sql to connect to a Microsoft SQL database. All works great... except if the SQL database goes down, firewall has the translate table, someone trips over a network cable anything that causes the connection between the radius and SQL to be disturbed, it just says There are no DB handles available instead of reconnecting... the only way I've found to reconnect, is to restart... Any comments or thoughts on this problem? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Hello,
It would be difficult to say how RADIUS would interact with the actual ACE server since it's a proprietary system. In 2002 I thought about going down this route and I'm summarizing from the 5 page SecurId integration document. You must write code that uses RSA's 'RSA Agent' software to communicate with the RSA ACE server. You must become a partner a a cost of ten thousand dollars for each product each year you provide the product(s). You must pay RSA twenty percent of your product's licensing fee. And you must have RSA certify it and may be required to provide a training program for RSA certification technicians. The sublicense agreement with RSA is incompatible with any open source software. The best thing to do is use FreeRadius as a proxy to the RSA RADIUS server. From a client's point of view the ACE RADIUS server may require a simple CHAP/PAP transaction or there may be challenges asking for more information. It depends on the RSA server configuration. darshak wrote: Hi All I m new to AAA things.I want how can I support RSA ACE/Server in freeradius. Can anyone has details How interaction is made between RADIUS and RSA/ACE-server?. in general scenario Rgds DArshak - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: shared secret mismatch
There's more going on the exchange than a simple authentication. The data in the Access-Request packet may have correct data for authentication. The server will correctly authenticate the entity. However server signs the response packet with a different secret than the client making the signature incorrect. The client must check the signature on the Access-Accept packet and if it's not correct must reject the authentication even though the reply type is Access-Accept. DilipSimha.N.M wrote: hi, If the shared-secret mismatches bwtween NAS and RADIUS server, then still the access-accept message is sent from RADIUS server to NAS. why is access-reject message not sent??? --DilipSimha - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: AccountingReq message authenticator
There is no way to generate a message authenticator in an Accounting-Request packet the usual way it's generated for an Access-Request. The accounting packet is signed by the client therefore there cannot be two signatures created for the entire the packet. By the very nature of creating signature the second signature will alter the packet's contents invalidating the first signature. The Message-Authenticator can be only one of two things. Either it's calculated as a hash of the attributes or it's a random number (like the Access-Request authenticator). From your information I suspect it's the former. You might try using the traditional MA calculation for the MA on just the attributes with an empty (zeroed) MA present and back patch the MA. If this works please let me know. Or, if someone has accounting packets generated with proper MA's please send them to me and I'll try some standard hashes. The MA is traditionally created as an MD5-HMAC of the shared secret and the entire packet's contents with an empty (16 byte) Message-Authenticator. For an accounting packet MA use just the attribute block instead of the entire packet try just the attributes with the empty MA. Ashwin Gobind wrote: Hi. Is there anyway to generate a message authenticator for an accounting request packet. At the moment I am using JRadius, I need to send an accounting request message to another radius server. However after I add the message authenticator and send to to another server, the other server complains about “Invalid message authenticator” (Shared secret is incorrect). Here is some code : //Proxy request to the wap gateway DatagramSocket socket = new DatagramSocket(); socket.setSoTimeout(5000); //Generate authenticator MessageDigest md5 = MessageDigest.getInstance(MD5); md5.reset(); md5.update((byte)req.getCode()); md5.update((byte)req.getIdentifier()); int length = req.getBytes().length; byte [] authenticator = req.getAuthenticator(); byte [] attributeBytes = req.getAttributeBytes(req.getAttributes(),0); for (int z=0; z authenticator.length ; z++ ) RadiusLog.debug(Autenticator[+z+] Before = + authenticator[z]); RadiusLog.debug(Autenticator Length: + authenticator.length); RadiusLog.debug(Attributes Length: + attributeBytes.length); RadiusLog.debug(Paket Length: + length); String sharedSecret = testing123; md5.update((byte)(length 8)); md5.update((byte)(length 0xff)); md5.update(authenticator, 0, authenticator.length); md5.update(attributeBytes, 0, attributeBytes.length); md5.update(sharedSecret.getBytes()); req.overwriteAttribute(AttributeFactory.newAttribute(AttributeDictionary.MESSAGE_AUTHENTICATOR, authenticator)); System.arraycopy(md5.digest(), 0, authenticator, 0, 16); “This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this link http://www.vodacom.net/legal/email.aspx http://www.vodacom.net/legal/email.asp - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP Public_key_exchange padding
This is dictated by TLS (actually OpenSSL's TLS). For the RSA key exchange TLS uses RSA_PKCS1_PADDING. Juan Daniel Moreno wrote: Hi, I am using a freeRadius 1.0.4 and I would like to know something about client_key_exchange(). Into this function it is necessary to specify a padding system that the server accepts. My question is, which of these paddings: RSA_PKCS1_PADDING RSA_PKCS1_OAEP_PADDING RSA_SSLV23_PADDING RSA_NO_PADDING is accepted by freeRadius 1.0.4? Thank you very much. Juan Daniel MORENO - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PAP and clear text
You must have missed the information in RFC 2865 (RADIUS), which is also a Fine Manual. The PAP password is XOR'd with the MD5 hash of the shared secret and the authenticator. You've been reading about the protocol prior to the RADIUS client's involvment. The same thing applies to CHAP, just to head you off. Chuck Slate wrote: Hi All. I have a few freeRADIUS newbie questions for you. I have always read and been told that PAP is insecure because it transmits passwords in clear text. However, If I sniff the communication between my NAS and server when PAP is used, the password is indeed obfuscated. It appears to be hashed. So my questions are: 1) First and foremost, am I interpreting this correctly? 2) If so, is it the shared secret defined in the clients.conf file that is used as a key for the hash? 3) If not, any clue as to what I am seeing, and in that case, what is the shared secret used for? As you can see, I am looking for some basic info about the flow of the connection. I have taken an honest shot at RTFM, but have not come across these details yet. Can someone please explain or point me to an explanation? Thanks in advance. Chuck - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authentication succeeds even with incorrect shared secret.
Sayantan Bhowmick wrote: Hi, I am using FreeRADIUS version 1.0.2 and I am trying to authenticate users using CHAP authentication. Everything works and authentication goes through except that users are authenticated successfully( provided userid and password id correct) irrespective of what is entered for the shared secret in the client. Is this a defect? Should'nt the RADIUS server check whether the client is using the correct shared secret? Thanks and Regards, -Sayantan. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: VSA id's higer than 255
Ascend (as Lucent) has been introducing tags with values higher than 256 in the VSA's for a while (first message I saw where the problem of long tags was mentioned was from January 2004). An example from their dictionary shows: ATTRIBUTE Ascend-MOH-Timeout 261 integer The format for the long tag VSA is the same as the standard Vendor-Specific attribute (8 bit tag, 8 bit length) but the sub-attribute tag field has been expanded to 16 bits. The sub-attribute length field remains 8 bits. All vendor specific attributes are coded using 16-bit attribute type in network byte order and Lucent-Vendor-Id (4846) as Vendor-Id. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attr Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id (cont) | Vendor Type(16-bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Length | Vendor-value.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- I believe the support for long Vendor-Specific tags was discussed here in the past with limited interest in support. It seems that this is on a NAS by NAS basis and only some of the VSA's are using the 16 bit tags. The solution seems to be to indicate that long tags are used by this NAS for particular vendors. Something like: 192.168.1.1 ... VendorLongTags=Ascend - indicating that Ascend VSA's use long tags and all other VSA's like Cisco) would be short. Ascend / Lucent VSA's do not always use long tag VSAs. This introduction of long tags is a real wart for every RADIUS server. There are probably other ways to have avoided 16 bit tags. Naturally the offender is too big to ignore and arbitrarily forced the issue. Remember that in the past Ascend (pre-Lucent) grabbed unassigned RADIUS attributes (from 119 to 255) without thinking there might be a problem with that either. Alan DeKok wrote: Fawaz Qamhawi [EMAIL PROTECTED] wrote: Any simple solution for that ? How are the attributes supposed to be encoded in the packet? The normal VSA's use one byte to represent vendor attributes. Since 287 won't fit into ne byte, something else has to be done here. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Weird situation proxying accounting packets
The reason is that the shared secret is wrong. RADIUS accounting packets are signed by the client and the signature is checked by the server. The authenticator is generated by the client from the packet contents and forms this signature. The server checks this signature. Authentication packets are not signed so no problem is detected by the server. The client checks for the response packet signature. The authenticator is a random number generated by the client. The packet is not signed, but the response packet is signed for the client to check. Why is this so? Authentication packets are trusted by the server. It's the client that must determine if the packet is signed correctly before it accepts authentication. The client doesn't trust the server. The server trusts accounting packets because they are correctly signed. Loris Fadda wrote: Hello guys, We use freeradius on a Debian 3.1 system, I've created an hybrid distro using packets from the testing tree to use the FR release 1.0.4 (deb revision 2). This box needs to proxy both auth and acct requests to a customer server that runs Cisco ACS 2.6. The NAS is Cisco AS5300. Proxyied authentication requests are satisfyed correctly, while accounting requests are sent back with a shared secret is incorrect from the customer radius server. Now, why if the secret is verified correctly on authentication I get this error on the accounting requests. Have you ever seen something like this? Notice that we checked out the secrets 1 times and they match perfectly, also, in my proxy.conf as well as in the clients.conf(the equivalent on FR ... I donno what the hell ACS uses) of the customer the shared secret is defined just once, I mean the same directive secret is used both for auth and acct . Is there any library or dictionary issue I've missed to check? Thanks for your attention any help will be really appreciated. Loris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
