Re: Questions about proxying
Hi, On Mon, Mar 17, 2003 at 11:47:58AM +0100, Toni Mueller wrote: On Tue, Feb 04, 2003 at 03:21:09PM -0600, Chris Parker wrote: At 10:04 PM 2/4/2003 +0100, Jacques Caruso wrote: Without success (the server continues to proxy the request for local users, and thus rejects our local users). This is a bug, and is fixed in the latest CVS. When looking up the well, this bug seems to have crept back in with the latest CVS as of yesterday. With identical configuration files, and working only out [ ... more imprecise stuff about the error clipped ] rebuilding with a CVS update from about half an hour ago solved it... ;-) Thank you!! Best, --Toni++ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Questions about proxying
Le Lundi 3 Février 2003 14:22, Alan DeKok a écrit :
The best thing to do would be to convince them that using a realm
for logins would be the best thing. That's how everybody else in the
world does it.
Yes, I am well aware of that, but hey, I simply don't have the power to
do that (*sigh*)...
I disagree. You only want to authenticate users who are in your
local domain. All other users should skip authentication, and go
directly to proxying.
Hem, yes, of course. Sorry for the misunderstanding.
The solution would be to put all of *your* users into a Unix group.
You can then do:
DEFAULT Group == myusers, Auth-Type := System
# NO fall-through!
DEFAULT Proxy-To-Realm = otherguy
Huh... a Unix group ? Since I'm working on a SQL backend, that isn't
possible, but all our local users are already in a group in the SQL DB.
I've thus added the Auth-Type attribute to the groups' attributes list
in the radgroupreply table. Here is the complete table :
mysql SELECT * FROM radgroupreply WHERE GroupName='internix';
++---+-++--+--+
| id | GroupName | Attribute | Value
| | op | prio |
++---+-++--+--+
| 1 | internix | Idle-Timeout| 1800
| | =|0 |
| 2 | internix | Service-Type| Framed-User
| | =|0 |
| 3 | internix | Framed-Protocol | PPP
| | =|0 |
| 4 | internix | Framed-IP-Address | 255.255.255.254
| | =|0 |
| 5 | internix | Framed-MTU | 1500
| | =|0 |
| 6 | internix | Framed-Compression | Van-Jacobson-TCP-IP
| | =|0 |
| 13 | internix | Reply-Message | Welcome to Monaco Internet Dial-Up
|server! | =|0 |
| 15 | internix | Simultaneous-Use| 1
| | =|0 |
| 38 | internix | Port-Limit | 1
| | =|0 |
| 39 | internix | Ascend-Maximum-Channels | 1
| | =|0 |
| 42 | internix | No-Such-Attribute |
| | := |0 |
| 48 | internix | Auth-Type | System
| | := |0 |
| 49 | internix | Fall-Through| No
| | := |0 |
++---+-++--+--+
13 rows in set (0.00 sec)
Without success (the server continues to proxy the request for local
users, and thus rejects our local users).
That way, the 'authorize' section discovers who owns what user, and
picks one of local authentication, or proxying.
That's exactly my goal, but I'm really lost... Here is the authorize
section used for the tests :
authorize {
preprocess
sql
suffix
}
And here is the transcript of 'radiusd -sfxxyz' run :
rad_recv: Access-Request packet from host 194.79.150.4:40941, id=224, length=59
User-Name = **
User-Password = **
NAS-IP-Address = 255.255.255.255
NAS-Port-Id = 0
modcall: entering group authorize
hints: Matched DEFAULT at 63
modcall[authorize]: module preprocess returns ok
radius_xlat: '**'
rlm_sql (sql): sql_set_user escaped user -- '**'
radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE UserName =
'**' ORDER BY id'
rlm_sql (sql): Reserving sql socket id: 4
radius_xlat: 'SELECT
radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op
FROM radgroupcheck,usergroup WHERE usergroup.UserName = '**' AND
usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id'
radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radreply WHERE UserName =
'**' ORDER BY id'
radius_xlat: 'SELECT
radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op
FROM radgroupreply,usergroup WHERE usergroup.UserName = '**' AND
usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.id'
rlm_sql (sql): Released sql socket id: 4
modcall[authorize]: module sql returns ok
rlm_realm: No '@' in User-Name = **, looking up realm NULL
rlm_realm: Found realm DEFAULT
rlm_realm: Setting Stripped-User-Name = **
rlm_realm: Proxying request from user ** to realm DEFAULT
rlm_realm: Adding Realm = DEFAULT
rlm_realm: Preparing to proxy authentication request to realm DEFAULT
modcall[authorize]: module
Re: Questions about proxying
At 10:04 PM 2/4/2003 +0100, Jacques Caruso wrote: Le Lundi 3 Février 2003 14:22, Alan DeKok a écrit : The solution would be to put all of *your* users into a Unix group. You can then do: DEFAULT Group == myusers, Auth-Type := System # NO fall-through! DEFAULT Proxy-To-Realm = otherguy Huh... a Unix group ? Since I'm working on a SQL backend, that isn't possible, but all our local users are already in a group in the SQL DB. I've thus added the Auth-Type attribute to the groups' attributes list in the radgroupreply table. Here is the complete table : mysql SELECT * FROM radgroupreply WHERE GroupName='internix'; | 42 | internix | No-Such-Attribute || := |0 | That looks a bit suspect to me. | 48 | internix | Auth-Type | System | := |0 | You don't want this in a reply. It is is 'Check-Item', put it in radgroupcheck. Without success (the server continues to proxy the request for local users, and thus rejects our local users). This is a bug, and is fixed in the latest CVS. When looking up the the realm NULL, the server returned the DEFAULT realm entry if you had one configured. It now properly returns nothing when looking up NULL if you don't have a specific NULL realm entry. modcall[authorize]: module sql returns ok rlm_realm: No '@' in User-Name = **, looking up realm NULL rlm_realm: Found realm DEFAULT rlm_realm: Setting Stripped-User-Name = ** rlm_realm: Proxying request from user ** to realm DEFAULT rlm_realm: Adding Realm = DEFAULT rlm_realm: Preparing to proxy authentication request to realm DEFAULT Yup, you need to upgrade to the latest CVS version to fix this bug. -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | @ @ |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Questions about proxying
Jacques Caruso [EMAIL PROTECTED] wrote: Huh... a Unix group ? Since I'm working on a SQL backend, that isn't possible, but all our local users are already in a group in the SQL DB. I've thus added the Auth-Type attribute to the groups' attributes list in the radgroupreply table. Here is the complete table : mysql SELECT * FROM radgroupreply WHERE GroupName=3D'internix'; ... | 48 | internix | Auth-Type | System = | :=3D |0 | Auth-Type should be in the check list, not in the reply list. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Questions about proxying
Jacques Caruso [EMAIL PROTECTED] wrote: I have set up two FreeRADIUS (0.8.1, Debian packages recompiled) servers, with a MySQL replicating backend. Since we provide a local PoP for a national ISP, I need to proxy requests to their RADIUS server. The problem is, they don't use any realm for their users. The best thing to do would be to convince them that using a realm for logins would be the best thing. That's how everybody else in the world does it. The best solution would have been thus (IMHO) to try to authenticate from the SQL DB, and if that failed, to forward the request to their RADIUS. I disagree. You only want to authenticate users who are in your local domain. All other users should skip authentication, and go directly to proxying. The solution would be to put all of *your* users into a Unix group. You can then do: DEFAULT Group == myusers, Auth-Type := System # NO fall-through! DEFAULT Proxy-To-Realm = otherguy That way, the 'authorize' section discovers who owns what user, and picks one of local authentication, or proxying. This won't work, however, if one of their users has the same name as one of your users. This is why everyone uses realms... Another question is about post-proxying : I originally configured the RADIUS to send back a 'Framed-IP-Address' parameter based on the port number of the NAS (avoids me the hassle of rummaging through the radacct logs to find who had that IP at that hour), and an 'Ascend-Maximum-Channels' parameter to please the broken NAS. The home server, of course, doesn't If your RADIUS server is the one next to the NAS boxes, then it doesn't matter what the home server sends you. I've been unable to find any information about mangling server responses except two short posts on the mailing list saying these functions should be available in the pre-0.8 snapshots[1]. Fine ! I run on 0.8.1, so I should have those magical functions, but I didn't find them, even after grepping the docs directory like a maniac. Could someone just point me at the right document ? The current CVS head has these. Hmm.. Monaco... I'll probably be in Nice in June. That's just down the road... Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Questions about proxying
In article [EMAIL PROTECTED], Alan DeKok [EMAIL PROTECTED] wrote: Jacques Caruso [EMAIL PROTECTED] wrote: I have set up two FreeRADIUS (0.8.1, Debian packages recompiled) servers, with a MySQL replicating backend. Since we provide a local PoP for a national ISP, I need to proxy requests to their RADIUS server. The problem is, they don't use any realm for their users. The best thing to do would be to convince them that using a realm for logins would be the best thing. That's how everybody else in the world does it. Another option would be to use two different dialin numbers, one for your local users, one for the national ISP. Both numbers are terminated on the same line and equipment, ofcourse. You can then differentiate by using Called-Station-Id. Mike. -- Anyone who is capable of getting themselves made President should on no account be allowed to do the job -- Douglas Adams. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
