Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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 :-)
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 :-)