Hi Tim, You can't authenticate to the /etc/passwd file using PEAP/MS-CHAPv2. Any CHAP based authentication mechanism requires the server to have access to the *clear text* passwords.
If you want to use PEAP/MS-CHAPv2, then you'll need to create definitions of your users either in a local (or other) database with clear text (or trivially reversible) passwords. If you want to use /etc/passwd, you could switch to EAP-TTLS/PAP. Since PAP sends the password in clear text (don't worry, it's inside the outer TTLS tunnel so it's not visible in the air), your server doesn't need the clear text held locally. It simply applies the same crypt algorithm to the received password and checks the result against your /etc/passwd file. Regards, Guy > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Tim Winders > Sent: 13 December 2004 15:55 > To: [EMAIL PROTECTED] > Subject: Re: rlm_eap_tls not built because OpenSSL not found > > > >> Mon Dec 13 07:02:02 2004 : Info: rlm_eap_tls: Length Included > >> Mon Dec 13 07:02:02 2004 : Error: TLS_accept:error in > SSLv3 read client > >> certificate A Mon Dec 13 07:02:02 2004 : Info: > rlm_eap_tls: Received > >> EAP-TLS ACK message > > > > That is not a show stopper. TLS is complaining about the client > > certificate you don't need for PEAP, but should process the request > > anyway. Examine the debug output to see if there is any > other failure. > > > >> I am trying to connect to a Cisco AP1200 from a Windows XP SP2 > >> client. The client has Network Authentication Open, Data > Encryption > >> WEP, EAP Type Protected EAP (PEAP), Authentication Method: Secured > >> password (EAP-MSCHAP v2). > > > > Why open and WEP? Why not WPA TKIP? The AP and supplicant should > > support this. > > No reason. I have changed the configuration to WPA/TKIP. > Here is the > degub output from radiusd after I have applied the MS hotfix > as referenced > in a previous message and have changed the AP and client > configuration to > WPA/TKIP. > > --- Walking the entire request list --- > Cleaning up request 22 ID 236 with timestamp 41bdb896 > Nothing to do. Sleeping until we see a request. > rad_recv: Access-Request packet from host 10.0.1.231:21646, id=237, > length=134 > User-Name = "twinders" > Framed-MTU = 1400 > Called-Station-Id = "0012.7f75.d940" > Calling-Station-Id = "0090.4b65.34a5" > Service-Type = Login-User > Message-Authenticator = 0xdc3d497356c2a583f2eaf7954c684d3a > EAP-Message = 0x0201000d017477696e64657273 > NAS-Port-Type = Wireless-802.11 > NAS-Port = 512 > NAS-IP-Address = 10.0.1.231 > NAS-Identifier = "sub-ap1" > Processing the authorize section of radiusd.conf > modcall: entering group authorize for request 23 > modcall[authorize]: module "preprocess" returns ok for request 23 > modcall[authorize]: module "chap" returns noop for request 23 > modcall[authorize]: module "mschap" returns noop for request 23 > modcall[authorize]: module "digest" returns noop for request 23 > rlm_realm: No '@' in User-Name = "twinders", looking up > realm NULL > rlm_realm: No such realm "NULL" > modcall[authorize]: module "suffix" returns noop for request 23 > rlm_eap: EAP packet type response id 1 length 13 > rlm_eap: No EAP Start, assuming it's an on-going EAP conversation > modcall[authorize]: module "eap" returns updated for request 23 > users: Matched entry DEFAULT at line 152 > modcall[authorize]: module "files" returns ok for request 23 > modcall: group authorize returns updated for request 23 > rad_check_password: Found Auth-Type EAP > auth: type "EAP" > Processing the authenticate section of radiusd.conf > modcall: entering group authenticate for request 23 > rlm_eap: EAP Identity > rlm_eap: processing type tls > rlm_eap_tls: Initiate > rlm_eap_tls: Start returned 1 > modcall[authenticate]: module "eap" returns handled for request 23 > modcall: group authenticate returns handled for request 23 > Sending Access-Challenge of id 237 to 10.0.1.231:21646 > EAP-Message = 0x010200061920 > Message-Authenticator = 0x00000000000000000000000000000000 > State = 0xe2c50ab039bff81ff87783b7c4dc1736 > Finished request 23 > Going to the next request > --- Walking the entire request list --- > Waking up in 6 seconds... > --- Walking the entire request list --- > Cleaning up request 23 ID 237 with timestamp 41bdb8b7 > Nothing to do. Sleeping until we see a request. > > > > > I see where it matches the DEFALT entry in the users file. This is > simply: > > DEFAULT Auth-Type = System > Fall-Through = 1 > > I am trying to authenticate to the /etc/passwd file on the > system. Dial > up PPP users are able to connect and authenticate OK using > the default > Framed-User service type: > > DEFAULT Service-Type == Framed-User > Framed-IP-Address = 255.255.255.254, > Framed-MTU = 576, > Service-Type = Framed-User, > Fall-Through = Yes > > > Perhaps the problem is here? I am new to freeradius and may > have missed > something here. > > -- > > Tim Winders > Associate Dean of Information Technology > South Plains College > Levelland, TX 79336 > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavours to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
