Re: ms-chap authentication with client tool?
You could try using the windows program NTRadPing from http://www.dialways.com/download/.It has a "CHAP" checkbox. HTH,Patrick On 1/31/06, Phil Mayers <[EMAIL PROTECTED]> wrote: DilipSimha.N.M wrote:> hi,>> is there any simple tool(other than jradius) which can be used as radius> client and which can be used to test> mschap authentication??> if so, please give the packet contents for radius client and the users > file check-items. 1. run FreeRadius in debugging mode 2. perform a successful MS-CHAP authentication with a "real" client 3. copy the following info from the FreeRadius debugging output: User-Name = "user"MS-CHAP-Challenge = 0xBYTESMS-CHAP2-Response = 0xBYTES 4. with that info, create a file containing a radius request:Service-Type = Framed-UserFramed-Protocol = PPP User-Name = "user"MS-CHAP-Challenge = 0xBYTESMS-CHAP2-Response = 0xBYTESCalling-Station-Id = "something"NAS-IP-Address = 192.168.1.2NAS-Port = 1 5. run the command "radclient -s -f $FILE $HOST auth $SECRET"The radius server will authenticate that request every time. Since thechallenge from a real NAS is essentially random there is only a low (but not zero) risk in having the info in a file.You may need to edit your users file to disable things such as IPaddress pool assignment or such, but it will basically work fine. Suchediting is dependent on your local configuration. -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: Authenticating CHAP-Password to Pam (Kerberos 5 to AD)
Phil, Thanks.In another thread I read, you wrote:---The MS-CHAP module requires either the MD4-based NT password hash, theplaintext password from which it can derive the NT has, or callout toSamba & domain membership.---Does this mean that if I setup Samba on this box, get it to be a member of the domain exchanging Domain UIDs and passwords, I could then authenticate to Samba from my MS-CHAP-speaking NAS? BTW, for any non-native English speakers, if you want the definition of SOL, e-mail me privately and I'll explain.PatrickOn 1/27/06, Phil Mayers <[EMAIL PROTECTED]> wrote: Patrick Bartkus wrote:>> Has this been solved or am I SOL?It is not a code bug. It is a fundamental feature of the algorithm. It*cannot* be solved. You are, as you put it, SOL. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Authenticating CHAP-Password to Pam (Kerberos 5 to AD)
Please tell me someone has fixed this problem.I'm trying to authenticate an Ascend MAX dial-up server back to Windows Active Directory. I am using a local unix group for authorization.I have Pam set up on my system and it uses Kerberos 5 to authenticate to AD just fine. But I'm getting:auth: type "PAM" Processing the authenticate section of radiusd.confmodcall: entering group authenticate for request 0rlm_pam: Attribute "User-Password" is required for authentication. Cannot use "CHAP-Password". modcall[authenticate]: module "pam" returns invalid for request 0I did some checking and found this posting from 2003 basically saying it can't be done: http://www.mail-archive.com/freeradius-users@lists.cistron.nl/msg19439.htmlI do have other options other than the Windows Domain authentication, but I was not wanting to pursue them unless I had to.Has this been solved or am I SOL? Patrick - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: want to reject if not in a unix group
Thanks, Alan! This worked great! >From reading the Jonathan Hassell _Radius_ book, I thought realms were just for cross-ISP authentication. But you've shown me a whole new use for them. That's the wonderful thing about freeradius. It will do about anything you want; and there are probably 3 ways to do it! It's only a matter of what you configure where (only? :-) ). Thanks again for your advice. Patrick >>> [EMAIL PROTECTED] 04/28/04 04:52PM >>> "Patrick Bartkus" <[EMAIL PROTECTED]> wrote: > What I want it to do is check that if a request comes from my Lucent > MAX 6000 dial-up server, that it verifies that this user is a member of > a unix group called dialupgrp. I put the Lucent NAS in a huntgroup > called dialserver. If the user is in the unix group "dialupgrp," then > check the user name / password combination by passing it request over > the legacy radius server. If the user name is not in the unix group > called dialupgrp, then send back a Access-Reject. That's not a problem. > My problem is that my radius server is passing the request onto the > other even when it does match my users file processing Because the server is looking at more than the "users" file. > rlm_realm: No '@' in User-Name = "aa0781", looking up realm NULL > rlm_realm: Found realm "NULL" > rlm_realm: Adding Stripped-User-Name = "aa0781" > rlm_realm: Proxying request from user aa0781 to realm NULL > rlm_realm: Adding Realm = "NULL" > rlm_realm: Preparing to proxy authentication request to realm > "NULL" So... you've configured the NULL realm to proxy all requests to another server. So even if the "users" file entries match, you didn't *over-ride* that command to proxy the packet. Further, your Auth-Type configuration is inconsistent > modcall[authorize]: module "preprocess" returns ok for request 2 > rlm_chap: Setting 'Auth-Type := CHAP' So for CHAP requests, it sets Auth-Type to CHAP. You also have the following in your "users" file: > DEFAULT Huntgroup-Name == "dialserver", Group != "dialupgrp", Auth-Type > = Reject Note that the "users" file entry matches AFTER the "chap" module is processed. You said "Auth-Type = Reject", which means "Set it to reject, if not already set to something else". It's already set to CHAP, so the request to set it to REJECT is ignored. Change the entry to do "Auth-Type := Reject". That will be a bit closer to what you want. You also have: > # First setup all accounts to be checked against the UNIX /etc/passwd. > # (Unless a password was already given earlier in this file). > # > DEFAULT Auth-Type := System, Group == "dialupgrp" Which is pointless. It means you can't do CHAP, and your authenticating the users against /etc/password, rather than proxying them to another server. So... my recommendations: - delete the NULL realm - add a realm "proxy", with the information about the other server. - I don't think you need a huntgroup for the NAS, either. Delete it. - configure your "users" file as follows: #--- DEFAULT Client-IP-Address == ip.of.lucent.nas, Group == "dialupgrp", Proxy-To-Realm := "proxy" DEFAULT Client-IP-Address == ip.of.lucent.nas, Group != "dialupgrp", Auth-Type := Reject #--- Which pretty much does what you want. I presume that you have other users, logging in via other NASes, and doing other kinds of authentications. You can add those entries later in the "users" file, below those two. 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
want to reject if not in a unix group
uest 2 rlm_realm: No '@' in User-Name = "aa0781", looking up realm NULL rlm_realm: Found realm "NULL" rlm_realm: Adding Stripped-User-Name = "aa0781" rlm_realm: Proxying request from user aa0781 to realm NULL rlm_realm: Adding Realm = "NULL" rlm_realm: Preparing to proxy authentication request to realm "NULL" modcall[authorize]: module "suffix" returns updated for request 2 huntgroups: Matched dialserver at 52 users: Matched DEFAULT at 149 modcall[authorize]: module "files" returns ok for request 2 modcall[authorize]: module "mschap" returns noop for request 2 modcall: group authorize returns updated for request 2 Sending Access-Request of id 2 to 10.1.4.51:1645 User-Name = "aa0781" CHAP-Password = 0x01636e31a424f1a3eabda8bff99a922cb7 NAS-IP-Address = 10.1.160.1 NAS-Port = 20401 NAS-Port-Type = Async Service-Type = Framed-User Framed-Protocol = PPP Acct-Session-Id = "373416159" Ascend-Data-Rate = 21600 Ascend-Xmit-Rate = 21600 CHAP-Challenge = 0x82b00ad52d13518577fd67149c11348c Proxy-State = 0x313033 Thread 3 waiting to be assigned a request rad_recv: Access-Accept packet from host 10.1.4.51:1645, id=2, length=80 Thread 4 assigned request 2 Waking up in 4 seconds... Thread 4 handling request 2, (1 handled so far) Class = 0x5342522d434c20444e3d22414130373831222041543d22302200 Ascend-MTU = 1520 Ascend-Home-Network-Name = "gadoln" Proxy-State = 0x313033 modcall: entering group post-proxy for request 2 modcall[post-proxy]: module "eap" returns noop for request 2 modcall: group post-proxy returns noop for request 2 rad_lowerpair: Stripped-User-Name now 'aa0781' modcall: entering group authorize for request 2 modcall[authorize]: module "preprocess" returns ok for request 2 rlm_chap: WARNING: Auth-Type already set. Not setting to CHAP modcall[authorize]: module "chap" returns noop for request 2 modcall[authorize]: module "eap" returns noop for request 2 rlm_realm: Proxy reply, or no User-Name. Ignoring. modcall[authorize]: module "suffix" returns noop for request 2 huntgroups: Matched dialserver at 52 users: Matched DEFAULT at 149 modcall[authorize]: module "files" returns ok for request 2 modcall[authorize]: module "mschap" returns noop for request 2 modcall: group authorize returns ok for request 2 rad_check_password: Found Auth-Type rad_check_password: Auth-Type = Accept, accepting the user Sending Access-Accept of id 103 to 10.1.160.1:1025 Class = 0x5342522d434c20444e3d22414130373831222041543d22302200 Ascend-MTU = 1520 Ascend-Home-Network-Name = "gadoln" Finished request 2 Going to the next request --- Snip snip snip --- I modeled my entry from the entry in the FAQ of how to block users IN a specific unix group. I think it has to do something with the CHAP authentication. When I try it from NTRadPing, which doesn't use CHAP, it works like I want successfully. Somehow I'm not fully understanding the processing of users. Thanks! Patrick --- Patrick Bartkus, CCNP, CCDA, CNX, SCM Sr. Network Engineer GA Dept of Labor IT Network Services If truth were not absolute, how could there be justice? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
