Date: Wed, 26 Mar 2003 08:59:45 -0600 To: [EMAIL PROTECTED] From: Chris Parker <[EMAIL PROTECTED]> Subject: Re: Reply-To: [EMAIL PROTECTED]
At 11:56 AM 3/26/2003 +0530, Y Sreenivasulu wrote:
>Hi,
>I am using FreeRADIUS Server Version 0.7.1. The Server is cofigured for
>authentication types local and EAP. When I send an Access_Request
>with only user-password and NAS-Identifier, the Server is sending
>Access_Reject
>to the client. What authentication method is used by the Server for this
>request?
What does the server say in the debug output?
> In general what happens if none of the user-name, EAP-message are
>present in a request? The RFC 2865 is not describing much about this
>situation.
RFC 2865 is pretty clear:
4.1. Access-Request
Description
Access-Request packets are sent to a RADIUS server, and convey
information used to determine whether a user is allowed access to
a specific NAS, and any special services requested for that user.
An implementation wishing to authenticate a user MUST transmit a
RADIUS packet with the Code field set to 1 (Access-Request).
Upon receipt of an Access-Request from a valid client, an
appropriate reply MUST be transmitted.
An Access-Request SHOULD contain a User-Name attribute. It MUST
contain either a NAS-IP-Address attribute or a NAS-Identifier
attribute (or both).
It doesn't say that the server has to do anything other than give a
valid reply. Access-Reject is indeed a valid reply ( though it may
not be the one you want ).
>Has anyone tried this situation?
All of the currently implemented modules with FreeRADIUS rely on a
User-Name to lookup the valid password. If you want the server to
do password lookups based on other attributes, you'll need to either
modify an existing module, write a new module, or use the functinality
of 'rlm_perl' to authorize the request.
Also note that it doesn't matter if the server is configured for EAP
if you aren't sending an EAP request to it.
Hi Chris,
The description of RFC 2865 says user-name is SHOULD and SHOULD
doesn't mean absolute necessity. This can also be inferred from the table of
attributes given at the end of attributes description. The tables says there can
be 0-1 instances of user-name in 'Access-Request'.
The following is the servre output when only user-password and NAS-Identifier are sent
:
" rad_recv: Access-Request packet from host 205.149.182.39:3100, id=1, length=44
User-Password = "g\3536\270I\203t\020\255jIhh9\221\035"
NAS-Identifier = "wewe"
modcall: entering group authorize
rlm_eap: EAP-Message not found
modcall[authorize]: module "eap" returns noop
rlm_realm: Proxy reply, or no user name. Ignoring.
modcall[authorize]: module "suffix" returns noop
users: Matched DEFAULT at 325
modcall[authorize]: module "files" returns ok
modcall: group authorize returns ok
auth: No authenticate method (Auth-Type) configuration found for the request:
Rejecting the user
auth: Failed to validate the user.
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
SMUX connect try 2
Can't connect to SNMP agent with SMUX: Connection refused
--- Walking the entire request list ---
Waking up in 1 seconds...
SMUX connect try 3
Can't connect to SNMP agent with SMUX: Connection refused
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Sending Access-Reject of id 1 to 205.149.182.39:3100"
It is clear that the server is searching for user-name which is not found.
I think the RADIUS client should not be allowed to send such requests. After all,
the client is expected to provide details of whom to authenticate.
Regards,
Y Sreenivasulu
[EMAIL PROTECTED]
Note:
Unless otherwise noted, the information provided by this mail does not represent
the official statements or views of Ionic Microsystems.
Privileged/Confidential information may be contained in this message and may be
subject to legal privilege. Access to this e-mail by anyone other than the intended is
unauthorised. If you are not the intended recipient (or responsible for delivery of
the message to such person), you may not use, copy, distribute or deliver this message
(or any part of its contents ) to anyone or take any action in reliance on it. In such
case, you should destroy this message, and notify us immediately. If you have received
this email in error, please notify us immediately by e-mail or telephone and delete
the e-mail from any computer.
If you or your employer does not consent to internet e-mail messages of this kind,
please notify us immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail. As our company cannot accept responsibility for
any loss or damage arising from the use of this e-mail or attachments we recommend
that you subject these to your virus checking procedures prior to use.
<<application/ms-tnef>>
