Bug 702676 - Unable to assign multiple group profiles under freeradius-2 to successfully authenticated users
Summary: Unable to assign multiple group profiles under freeradius-2 to successfully a...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: freeradius
Version: 6.0
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: John Dennis
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-06 14:42 UTC by Ricky Nelson
Modified: 2018-11-14 14:34 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-11 22:02:31 UTC
Target Upstream Version:


Attachments (Terms of Use)

Comment 9 John Dennis 2011-05-11 22:00:11 UTC
Follow these steps as an example to show how add attributes on a local server when authenticating via a remote proxy.

1) Edit /etc/raddb/users on the remote proxy and add this text:
bob     Cleartext-Password := "hello"

Note: also make sure the remote proxy has the local server in its client list (e.g. /etc/raddb/clients and their secrets match)

2) create the file /etc/raddb/postproxy_users on the local server and add this text:
bob
    Framed-Filter-Id = "blatz"

3) Edit /etc/raddb/site-available/default on the local server, in the post-proxy section add:
    files

4) Edit /etc/raddb/modules/files on the local server, in the files section add this text:
    postproxy_usersfile = ${confdir}/postproxy_users

5) restart the server or run it in debug mode

6) test the user bob by doing this:
$ radtest bob hello localhost 0 testing123 
Sending Access-Request of id 225 to 127.0.0.1 port 1812
	User-Name = "bob"
	User-Password = "hello"
	NAS-IP-Address = 127.0.0.1
	NAS-Port = 0
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=225, length=27
	Filter-Id = "blatz"


The result is bob is authenticated and the Filter-Id specific to bob is returned. What happened?

1) auth request goes to local radius server

2) local radius server forward auth request to proxy

3) proxy server finds bob in it's users file, passwords match, proxy server sends Access-Accept to local server

4) local server receives Access-Accept, the post-proxy section executes because this is after a proxy request, the post-proxy section says run the "files" module. The files module has been configured with postproxy_usersfile. Inside postproxy_usersfile are the attributes for bob. The files module executes in the post-proxy phase and adds the attributes it found for the user, bob in our example.

5) local server returns the Access-Accept response with the attributes from both the proxy server and the local server.

The format for "users" files (including pre and post proxy) are in the users(5) man page, i.e. 

$ man 5 users

There are many ways to configure similar behaviour depending if you're using SQL or LDAP as backends instead of flat files. You can also use the attr_rewrite module, or probably several other ways.

Also note the distinction between the users files and the postproxy_users file. the users file does not get used when you proxy because that contains information only for users local to the local server, since you're proxying that won't come into play.

Hope this gets you over the hump :-)


Note You need to log in before you can comment on or make changes to this bug.