Authentication with existing MySQL database
Hello all, I've set up and configured freeradius to properly authenticate users using the MySQL database schema specified on the freeradius.org website. However, since we already have a different database set up with users' passwords that is updated by scripts when users change their passwords or their accounts are disabled etc, I would like to be able to pull their password hashes directly from that database. This is what I've tried so far to do so, but it has not worked. I've changed in the sql.conf file the authorize_check_query to the following, but left the authorize_reply_query untouched: authorize_check_query = "SELECT id, name as UserName, 'NT-Password' as Attribute, nthashpass as Value, ':=' as op \ FROM users \ WHERE name = '%{SQL-User-Name}' \ ORDER BY id" However, when I run freeradius -X, it appears that for some reason that setting is erased. The following is the pertinent output: sql: authorize_check_query = "" sql: authorize_reply_query = "SELECT id, UserName, Attribute, Value, op FROM radreply WHERE Username = '%{SQL-User-Name}' ORDER BY id" Then, when I try to authenticate a user, the following error is output: lm_sql (sql): sql_set_user escaped user --> ''******' radius_xlat: '' rlm_sql (sql): Reserving sql socket id: 4 rlm_sql (sql): SQL query error; rejecting user rlm_sql (sql): Released sql socket id: 4 modcall[authorize]: module "sql" returns fail for request 0 I'm guessing the SQL query error is related to the fact that authorize_check_query is now an empty string, but I'm not sure why that's the case. Anyone have any insight? -- Quentin Smith
Quentin Smith wrote:
However, when I run freeradius -X, it appears that for some reason that setting is erased. The following is the pertinent output:
Read the rest of the debug output. Which files is it reading? Which one contains the SQL configuration? Which one did you edit?
I'm guessing the SQL query error is related to the fact that authorize_check_query is now an empty string, but I'm not sure why that's the case.
You edited it locally. The default configuration doesn't have this issue. Find out which file was edited, and fix it. Alan DeKok.
Alan DeKok wrote:
Quentin Smith wrote:
However, when I run freeradius -X, it appears that for some reason that setting is erased. The following is the pertinent output:
Read the rest of the debug output. Which files is it reading? Which one contains the SQL configuration? Which one did you edit?
I edited the sql.conf file, which was the file being read.
I'm guessing the SQL query error is related to the fact that authorize_check_query is now an empty string, but I'm not sure why that's the case.
You edited it locally. The default configuration doesn't have this issue.
Find out which file was edited, and fix it.
Alan DeKok.
Quentin Smith
Alan DeKok wrote:
Quentin Smith wrote:
However, when I run freeradius -X, it appears that for some reason that setting is erased. The following is the pertinent output:
Read the rest of the debug output. Which files is it reading? Which one contains the SQL configuration? Which one did you edit?
I edited the sql.conf file, which was the file being read.
I'm guessing the SQL query error is related to the fact that authorize_check_query is now an empty string, but I'm not sure why that's the case.
You edited it locally. The default configuration doesn't have this issue.
Find out which file was edited, and fix it.
Alan DeKok.
After some closer inspection, I discovered the problem. In order to have the default configuration available for reference purposes, I had simply commented out the following line: authorize_check_query = "SELECT id, UserName, Attribute, Value, op \ and replaced it with the following line: authorize_check_query = "SELECT id, name as UserName, 'NT-Password' as Attribute, nthashpass as Value, ':=' as op \ However, I didn't realize that commenting the line didn't prevent the escaping of the return character at the end of the line, effectively commenting out the following lines as well. Deleting the backslash fixed the problem, and it now works as I intended. Thanks for the reply. -- Quentin Smith
participants (3)
-
Alan DeKok -
Quentin Smith -
Quentin Smith