rlm_sql: Failed to create the pair: Unknown attribute "DragonWave-Privilege-Level" requires a hex string, not "DragonWave-Super-User"
Greetings, I am setting up/migrating to a new Radius server. My current server is using flat files (users/clients). Not a huge deployment, but now have designs to scale larger. I've run into a problem with one reply attribute I can't seem to identify the problem. I've searched the documentation (and Googled), and while probably in from of my eyes, I can't seem to find the cause/solution. The same reply attributes work fine in my current/production server, but fail (and only when trying to include the "DragonWave-Privilege-Level" reply attribute). Now one note, in my production server in my user stanza I use the "=" operator for each of the reply attributes. However, in my new server, when using the "=" as the operator in the reply attribute I was receiving only one attribute upon authentication. I then thought I understood from the documentation that I needed to use "+=" in my reply attributes. After making that change, all the group attributes were returned. One difference may be that I am specifying the "group" attributes under each "user" (current/production) vs in a "group" which is referenced (new server)? I am in no way well versed in all the nuances of radius (but working that direction), so if I'm overlooking the obvious I would greatly appreciate a nudge in the right direction. Thank you very much, tony #************************* # #// CURRENT SERVER # #************************* # # System information # admin@radius:/home/admin# uname -a Linux radius 3.5.0-45-generic #68~precise1-Ubuntu SMP Wed Dec 4 16:18:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux admin@radius:/home/admin# cat /etc/issue Ubuntu 12.04.4 LTS \n \l admin@radius:/home/admin# freeradius -v freeradius: FreeRADIUS Version 2.1.10, for host x86_64-pc-linux-gnu, built on Feb 24 2014 at 15:16:50 Copyright (C) 1999-2010 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License. For more information about these matters, see the file named COPYRIGHT. # # /etc/freeradius/users # "testuser" ClearText-Password := "tester" Reply-Message = "Hello, %{User-Name}", Mikrotik-Group = "full", DragonWave-Privilege-Level = "DragonWave-Super-User", APC-Service-Type = 1, APC-Outlets = "1,2,3,4,5,6,7,8" # # radtest and result # admin@radius:/home/admin# radtest testuser tester localhost 10 testing123 0 10.10.0.120 Sending Access-Request of id 25 to 127.0.0.1 port 1812 User-Name = "testuser" User-Password = "tester" NAS-IP-Address = 10.10.0.120 NAS-Port = 10 Framed-Protocol = PPP rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=25, length=70 Reply-Message = "Hello, testuser" Mikrotik-Group = "full" DragonWave-Privilege-Level = DragonWave-Super-User APC-Service-Type = Admin APC-Outlets = "1,2,3,4,5,6,7,8" #************************* # #// NEW SERVER # #************************* admin@radius1:/home/admin# uname -a Linux radius1.mydomain.net 2.6.32-431.20.3.el6.i686 #1 SMP Thu Jun 19 19:51:30 UTC 2014 i686 i686 i386 GNU/Linux admin@radius1:/home/admin# cat /etc/issue CentOS release 6.5 (Final) Kernel \r on an \m admin@radius1:/home/admin# radiusd -v radiusd: FreeRADIUS Version 2.1.12, for host i386-redhat-linux-gnu, built on Oct 3 2012 at 01:20:08 Copyright (C) 1999-2011 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License. For more information about these matters, see the file named COPYRIGHT. #************************* # #// radtest # #************************* admin@radius1:/home/admin# radtest testuser tester 216.x.x.x 10 testing123 0 10.10.0.120 Sending Access-Request of id 119 to 216.x.x.x port 1812 User-Name = "testuser" User-Password = "tester" NAS-IP-Address = 10.10.0.120 NAS-Port = 10 Message-Authenticator = 0x00000000000000000000000000000000 rad_recv: Access-Reject packet from host 216.x.x.x port 1812, id=119, length=20 #************************* # #// Partial debug output # #************************* Ready to process requests. rad_recv: Access-Request packet from host 216.x.x.x port 50707, id=119, length=75 User-Name = "testuser" User-Password = "tester" NAS-IP-Address = 10.10.0.120 NAS-Port = 10 Message-Authenticator = 0x17fec73c577cb5fd95d9dd3656c3a8db # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++- entering policy filter_username {...} +++? if (User-Name =~ /^ /) ? Evaluating (User-Name =~ /^ /) -> FALSE +++? if (User-Name =~ /^ /) -> FALSE +++? if (User-Name =~ / $$/) ? Evaluating (User-Name =~ / $$/) -> FALSE +++? if (User-Name =~ / $$/) -> FALSE +++? if (User-Name != "%{tolower:%{User-Name}}") expand: %{User-Name} -> testuser expand: %{tolower:%{User-Name}} -> testuser ? Evaluating (User-Name != "%{tolower:%{User-Name}}") -> FALSE +++? if (User-Name != "%{tolower:%{User-Name}}") -> FALSE ++- policy filter_username returns notfound ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "testuser", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop [sql] expand: %{User-Name} -> testuser [sql] sql_set_user escaped user --> 'testuser' rlm_sql (sql): Reserving sql socket id: 3 [sql] expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'testuser' ORDER BY id [sql] User found in radcheck table [sql] expand: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radreply WHERE username = 'testuser' ORDER BY id [sql] expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'testuser' ORDER BY priority [sql] expand: SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id -> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'NOC-Admin' ORDER BY id [sql] User found in group NOC-Admin [sql] expand: SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = '%{Sql-Group}' ORDER BY id -> SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'NOC-Admin' ORDER BY id rlm_sql: Failed to create the pair: Unknown attribute "DragonWave-Privilege-Level" requires a hex string, not "DragonWave-Super-User" rlm_sql (sql): Error getting data from database [sql] Error retrieving reply pairs for group NOC-Admin [sql] Error processing groups; rejecting user rlm_sql (sql): Released sql socket id: 3 ++[sql] returns fail Using Post-Auth-Type Reject # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> testuser attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 0 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 0 Sending Access-Reject of id 119 to 216.x.x.x port 50707 Waking up in 4.9 seconds. Cleaning up request 0 ID 119 with timestamp +54 Ready to process requests. #************************* # #// Manual query based on radiusd -X debug output # #************************* mysql> SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'NOC-Admin' ORDER BY id; +----+---------------------+----------------------------+-----------------------+----+ | id | groupname | attribute | value | op | +----+---------------------+----------------------------+-----------------------+----+ | 1 | NOC-Admin | Mikrotik-Group | full | += | | 7 | NOC-Admin | APC-Service-Type | 1 | += | | 8 | NOC-Admin | APC-Outlets | "1,2,3,4,5,6,7,8" | += | | 10 | NOC-Admin | DragonWave-Privilege-Level | DragonWave-Super-User | += | +----+---------------------+----------------------------+-----------------------+----+ 5 rows in set (0.00 sec) mysql> # /usr/share/freeradius/dictionary.dragonwave #************************* # #// Dragonwave Dictionary Definition # #************************* # -*- text -*- # http://www.dragonwaveinc.com # # $Id$ # VENDOR DragonWave 7262 BEGIN-VENDOR DragonWave # Used to determine the user login privilege level. ATTRIBUTE DragonWave-Privilege-Level 1 integer # Read-only access. VALUE DragonWave-Privilege-Level DragonWave-Admin-User 1 # Limited read-write access. VALUE DragonWave-Privilege-Level DragonWave-NOC-User 2 # Unlimited read-write access. VALUE DragonWave-Privilege-Level DragonWave-Super-User 3 END-VENDOR DragonWave
Tony DeMatteis wrote:
I am setting up/migrating to a new Radius server. My current server is using flat files (users/clients). Not a huge deployment, but now have designs to scale larger. I've run into a problem with one reply attribute I can't seem to identify the problem. I've searched the documentation (and Googled), and while probably in from of my eyes, I can't seem to find the cause/solution. The same reply attributes work fine in my current/production server, but fail (and only when trying to include the "DragonWave-Privilege-Level" reply attribute).
The dragonwave dictionary isn't on the new server. Add it to the new server, and it will work.
Now one note, in my production server in my user stanza I use the "=" operator for each of the reply attributes. However, in my new server, when using the "=" as the operator in the reply attribute I was receiving only one attribute upon authentication. I then thought I understood from the documentation that I needed to use "+=" in my reply attributes.
Yes, += is what you want to use.
After making that change, all the group attributes were returned. One difference may be that I am specifying the "group" attributes under each "user" (current/production) vs in a "group" which is referenced (new server)?
I don't know what that means. The functionality of the "users" file is documented. See "man users", and the comments at the start of the default file.
# /usr/share/freeradius/dictionary.dragonwave
Which is on the old server, and isn't on the new one. I've added it to the default release, so it will be there. At least for vendors who ship recent versions of the server instead of 2.1.12. Alan DeKok.
Hi Alan, Thank you for your reply. Please see my comments inline as well. And thank you for your continued patience! On 07/07/2014 09:10 AM, Alan DeKok wrote:
Tony DeMatteis wrote:
I am setting up/migrating to a new Radius server. My current server is using flat files (users/clients). Not a huge deployment, but now have designs to scale larger. I've run into a problem with one reply attribute I can't seem to identify the problem. I've searched the documentation (and Googled), and while probably in from of my eyes, I can't seem to find the cause/solution. The same reply attributes work fine in my current/production server, but fail (and only when trying to include the "DragonWave-Privilege-Level" reply attribute). The dragonwave dictionary isn't on the new server. Add it to the new server, and it will work. As you pointed out, the dragonwave dictionary is not included as one of the dictionaries in a default installation. So I added the needed dictionary to the /usr/share/freeradius directory (new server). Now one note, in my production server in my user stanza I use the "=" operator for each of the reply attributes. However, in my new server, when using the "=" as the operator in the reply attribute I was receiving only one attribute upon authentication. I then thought I understood from the documentation that I needed to use "+=" in my reply attributes. Yes, += is what you want to use.
After making that change, all the group attributes were returned. One difference may be that I am specifying the "group" attributes under each "user" (current/production) vs in a "group" which is referenced (new server)? I don't know what that means.
The functionality of the "users" file is documented. See "man users", and the comments at the start of the default file. Forgive my ignorance, I will review the man users file. What I meant was that, as I learn more, I don't believe by adding specific attributes to a single user in the user file (old server) that I was effecting a groupreply. On the new server I am specifically defining the reply attributes I want returned and adding a profile (group) to the user. So I noted that, not expecting there to be any difference in the operator of the reply attr but, not being absolutely sure.
# /usr/share/freeradius/dictionary.dragonwave This is the path of the dictionary on the New Server Which is on the old server, and isn't on the new one.
I've added it to the default release, so it will be there. At least for vendors who ship recent versions of the server instead of 2.1.12. Thank you very much =)
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Tony DeMatteis wrote:
As you pointed out, the dragonwave dictionary is not included as one of the dictionaries in a default installation. So I added the needed dictionary to the /usr/share/freeradius directory (new server).
You also need to add it to the main "dictionary" file. See that file for hundreds of examples. Alan DeKok.
Hi Alan, That was the missing piece. I thought that all of the dictionary files in the /usr/share/freeradius directory were $INCLUDE'd, and I had added the dictionary.dragonwave file/definitions to the directory. Assuming bites again... Thank you again! Best admin@radius1:/home/admin# radtest testuser testpw 216.x.x.x 10 testing123 0 10.10.0.102 Sending Access-Request of id 87 to 216.19.9.6 port 1812 User-Name = "testuser" User-Password = "testpw" NAS-IP-Address = 10.10.0.102 NAS-Port = 10 Message-Authenticator = 0x00000000000000000000000000000000 rad_recv: Access-Accept packet from host 216.x.x.x port 1812, id=87, length=79 Mikrotik-Group = "full" APC-Service-Type = Admin APC-Outlets = "1,2,3,4,5,6,7,8" DragonWave-Privilege-Level = DragonWave-Super-User On 07/07/2014 07:24 PM, Alan DeKok wrote:
Tony DeMatteis wrote:
As you pointed out, the dragonwave dictionary is not included as one of the dictionaries in a default installation. So I added the needed dictionary to the /usr/share/freeradius directory (new server). You also need to add it to the main "dictionary" file. See that file for hundreds of examples.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
Tony DeMatteis