[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: want to reject if not in a unix group
From:       "Patrick Bartkus" <Patrick.Bartkus () dol ! state ! ga ! us>
Date:       2004-04-30 14:40:46
Message-ID: s0922d3f.090 () gwiadrs ! private ! gdol
[Download RAW message or body]

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

>>> aland@ox.org 04/28/04 04:52PM >>>
"Patrick Bartkus" <Patrick.Bartkus@dol.state.ga.us> 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
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic